Snapshot to nie backup – i kiedy snapshot zabije Ci wydajność

„Zanim zaktualizuję – zrobię snapshot, będę bezpieczny." Zdanie prawdziwe i fałszywe zarazem. Snapshot to świetne narzędzie do chwilowego cofnięcia zmiany, ale nie jest backupem – i mylenie tych dwóch rzeczy potrafi kosztować całe środowisko. Do tego snapshot zostawiony „na wszelki wypadek" na tygodnie potrafi po cichu rozłożyć wydajność maszyny. Rozłóżmy to spokojnie.

Czym naprawdę jest snapshot

Snapshot to zapisany stan maszyny w danej chwili – zwykle realizowany techniką copy-on-write: od momentu wykonania snapshotu nowe zapisy trafiają w osobne miejsce, a oryginalne bloki są „zamrażane", żeby dało się do nich wrócić. Kluczowe słowo: snapshot jest zależny od oryginalnego dysku i tego samego storage. To nie jest niezależna kopia danych – to raczej „zakładka" w tym samym pliku/wolumenie.

Z tej jednej cechy wynika wszystko, co dalej.

Dlaczego snapshot to nie backup

Backup to niezależna kopia, która przeżyje śmierć oryginału. Snapshot tej właściwości nie ma:

• Ginie razem ze storage. Jeśli padnie dysk, macierz albo pula ZFS, na której leży maszyna – snapshot ginie razem z nią. Jest w tym samym miejscu co dane, które miałby chronić.
• Nie chroni przed ransomware ani skasowaniem VM. Skasowanie maszyny albo zaszyfrowanie storage zabiera też snapshoty. Backup offsite z osobnymi poświadczeniami – nie.
• Jest przypięty do konkretnej maszyny. Nie przeniesiesz go łatwo na inny host w innej lokalizacji jak pełnej kopii.
• Nie ma retencji ani weryfikacji w sensie, w jakim ma je system backupu (test-restore, sumy kontrolne, kopie GFS).

Prosty test myślowy: jeśli serwerownia spłonie / macierz padnie / ktoś zaszyfruje storage – czy odzyskam dane? Ze snapshotu: nie. Z backupu offsite: tak. To cała różnica. (Jak zbudować backup, na którym naprawdę można polegać, opisaliśmy w tekście o test-restore.)

Kiedy snapshot zabija wydajność

Druga, mniej oczywista pułapka. Snapshot nie jest darmowy w czasie – im dłużej żyje i im więcej zmian od jego wykonania, tym większy koszt:

• qcow2 (pliki): po zrobieniu snapshotu maszyna zapisuje zmiany do warstwy nakładki (copy-on-write). Im dłużej snapshot istnieje i im więcej zapisów, tym grubszy łańcuch delt – rosną narzuty na każdą operację I/O, a późniejsze scalanie (usunięcie snapshotu) potrafi mocno obciążyć dysk. Kilka zapomnianych snapshotów qcow2 na aktywnej maszynie to typowa przyczyna „nagle wszystko zwolniło".
• LVM-thin: snapshot zużywa miejsce w puli thin. Długo żyjący snapshot aktywnej maszyny puchnie – a przepełnienie puli thin jest groźne: może unieruchomić wszystkie wolumeny w tej puli. To jeden z gorszych scenariuszy.
• ZFS: snapshoty są tanie w wykonaniu i „lekkie" na starcie, ale trzymają bloki – dopóki snapshot istnieje, ZFS nie może zwolnić danych, które od tego czasu skasowałeś. Zapomniane snapshoty potrafią po cichu zapełnić pulę.
• Ceph (RBD): snapshoty też mają swój koszt przy intensywnych zapisach – zasada „krótko żyjące" obowiązuje tak samo.

Wniosek jest wspólny dla wszystkich: snapshot ma być krótkotrwały. Zapomniany snapshot to dług, który rośnie.

Różnice między storage w skrócie

• qcow2 (plik): snapshoty tak, także ze stanem RAM. Uwaga: łańcuch delt rośnie – kasuj szybko.
• LVM-thin: snapshoty thin. Uwaga: pilnuj zajętości puli – przepełnienie potrafi unieruchomić wolumeny.
• ZFS: snapshoty natywne, tanie na starcie. Uwaga: trzymają skasowane bloki, dopóki żyją.
• Ceph (RBD): snapshoty tak. Uwaga: przy dużych zapisach mają koszt – trzymaj krótko.
• LVM „grube": brak wsparcia snapshotów maszyn.

To m.in. dlatego wybór storage jest decyzją strategiczną, a nie kosmetyczną.

Jak używać snapshotów z głową

Snapshot jest znakomity jako chwilowy „undo":

• Przed ryzykowną zmianą – aktualizacją systemu, wdrożeniem, zmianą konfiguracji – zrób snapshot.
• Zweryfikuj, że zmiana działa.
• Usuń snapshot od razu po potwierdzeniu (albo cofnij się do niego, jeśli coś poszło źle).

Trzy zasady, które oszczędzają kłopotów:

• Snapshoty żyją godziny, nie tygodnie. Ustaw sobie regułę: żaden snapshot nie zostaje na noc bez powodu.
• Nie traktuj snapshotu jako kopii przed weekendem/wakacjami. Od tego jest backup.
• Monitoruj zapomniane snapshoty. Regularnie sprawdzaj, czy na maszynach nie wiszą stare snapshoty – to jedno z najczęstszych, cichych źródeł problemów wydajnościowych.

Snapshot i backup: uzupełniają się, nie zastępują

Najzdrowszy model to jedno i drugie:

• Snapshot – szybki, chwilowy bezpiecznik przy zmianach na żywej maszynie. Sekundy do wykonania, natychmiastowy rollback.
• Backup (PBS + kopia offsite) – niezależna, odtwarzalna kopia, która przeżyje awarię storage, skasowanie i ransomware. To on odpowiada za realne bezpieczeństwo danych.

Zrobić samemu czy zlecić?

Robienie i kasowanie snapshotów to codzienność każdego admina. Trudniejszy jest projekt całości: dobór storage pod obciążenie (qcow2/LVM-thin/ZFS/Ceph), polityka „żadnych zapomnianych snapshotów", monitoring zajętości pul oraz spięcie tego z sensownym backupem i test-restore. To obszar, w którym regularnie porządkujemy środowiska klientów – często zaczynając od usunięcia snapshotów, które od miesięcy dławiły produkcję.

FAQ

Czy mogę cofnąć maszynę do snapshotu bez utraty danych?

Cofnięcie (rollback) przywraca stan z chwili snapshotu – zmiany wykonane po nim przepadają. Snapshot to „wróć do punktu", nie „scal najlepsze z obu". Dlatego traktuj go jako krótkoterminowy bezpiecznik.

Dlaczego maszyna zwolniła po zrobieniu snapshotu?

Bo od momentu snapshotu każdy zapis obsługiwany jest przez warstwę copy-on-write. Im dłużej snapshot żyje i im więcej zapisów, tym większy narzut – szczególnie na qcow2. Usuń snapshot, gdy przestał być potrzebny.

Czy snapshot ZFS to już backup, skoro jest tani?

Nie. Snapshot ZFS leży na tej samej puli co dane – padnie razem z nią. Dopiero wysłanie snapshotu (`zfs send`) na inny system albo backup PBS offsite daje niezależną, odtwarzalną kopię.

Ile snapshotów mogę bezpiecznie trzymać?

Zasada nie brzmi „ile", tylko „jak długo": krótko. Kilka świeżych snapshotów jest w porządku; problemem są stare, zapomniane snapshoty na aktywnych maszynach – niezależnie od ich liczby.

Podsumowanie

Snapshot to chwilowy „undo", nie backup – ginie razem ze storage i nie chroni przed ransomware. Zostawiony na tygodnie zjada wydajność (najmocniej qcow2 i przepełniona pula LVM-thin). Używaj go krótko i celowo, a bezpieczeństwo danych oprzyj na niezależnym, testowanym backupie.

Chcesz uporządkować storage i backup w swoim środowisku Proxmox? Umów konsultację, zobacz Proxmox Backup Server i policz subskrypcje w kalkulatorze, albo napisz na proxmox@polsoft.pl / zadzwoń 32 209 80 39 (pon.–pt. 8:00–16:00).