Snapshot maszyny wirtualnej

Snapshot to migawka stanu maszyny wirtualnej w konkretnej chwili: dysk, pamięć i czasem konfiguracja sieci. Służy do cofnięcia aktualizacji systemu albo instalacji programu, gdy coś pójdzie nie tak w ciągu godzin, nie tygodni. Na hypervisorze w Proxmox albo w VMware robi się go przed zmianą, a nie „na wszelki wypadek na stałe”. To narzędzie cofnięcia, nie magazyn historii firmy.

Snapshot nie jest kopią poza serwerem. Leży na tej samej macierzy co maszyna produkcyjna. Awaria kontrolera, ransomware na hypervisorze i pożar szafy kasują oryginał razem z migawką. Dlatego po udanej zmianie snapshot się kasuje, a ochronę długoterminową daje backup i archiwizacja według reguły 3-2-1, nie łańcuch migawek z całego kwartału.

Zostawiony snapshot puchnie. Każdy zapis na dysku maszyny trafia do delty, a oryginalny dysk zostaje zamrożony. Po tygodniu delta bywa większa niż sama maszyna, a wydajność spada, bo hypervisor czyta dwie warstwy. Po miesiącu usunięcie migawki potrafi zająć godziny i zablokować inne operacje na storage. Dlatego polityka brzmi: snapshot na zmianę, kasowanie tego samego dnia albo następnego rana po teście.

Częsty błąd to mylenie snapshotu z backupem w rozmowie z zarządem. Drugi błąd to snapshot przed każdą nocną aktualizacją i brak miejsca na dysku rano. Trzeci błąd to snapshot maszyny z otwartą bazą danych bez spójności aplikacji: cofnięcie wraca do stanu, w którym baza uważa transakcję za niedokończoną. Program backupu rozumiejący hypervisor, na przykład Veeam, bierze spójny obraz inaczej niż ręczna migawka „na szybko”.

Snapshot ma sens przed łatką, przed zmianą sterownika i przed migracją dysku. Nie ma sensu jako jedyna ochrona serwera plików ani jako archiwum faktur. Gdy ktoś mówi „mamy snapshoty, więc nie potrzebujemy drugiej lokalizacji”, warto pokazać, gdzie fizycznie leżą pliki delty. Jeśli w tej samej szafie co produkcja, reguła 3-2-1 nadal jest niedomknięta.

W dokumentacji zmiany zapisujemy: kto zrobił snapshot, o której godzinie, na której maszynie i do kiedy wolno go trzymać. Bez tej notatki po urlopie administratora zostaje migawka bez właściciela, a storage krzyczy o brak miejsca w najmniej wygodnym momencie. Kasowanie po udanym teście jest częścią procedury, nie opcją. Jeśli test się nie udał, cofamy stan i dopiero potem planujemy drugą próbę, a nie dokładamy kolejną migawkę na poprzednią. Łańcuch trzech snapshotów pod rząd to sygnał, że zmiana powinna iść na kopię maszyny albo na środowisko testowe, a nie na produkcję z coraz grubszą deltą.

Przed większą zmianą na produkcji warto mieć też punkt z programu backupu z tej samej doby, nie tylko migawkę. Snapshot cofa zmianę hypervisora. Backup chroni przed awarią całego hosta. Obie rzeczy w jednym zdaniu oferty mylą klienta. Rozdzielamy je w dokumentacji zmiany: migawka do kasacji po teście, kopia zostaje według retencji. Gdy miejsce na storage kończy się przez stare snapshoty, pierwszym krokiem jest lista migawek z datą, a nie dokupowanie dysków. Po posprzątaniu zwykle wraca kilkaset gigabajtów i spokój na kolejne wdrożenia. Dopiero gdy lista jest pusta, a miejsce nadal znika, szukamy wzrostu danych produkcyjnych. Taki porządek zajmuje godzinę i wraca wielokrotnie przy każdej aktualizacji.