Czy snapshot to backup? Snapshot vs backup – różnice i kiedy czego używać

Snapshot nie jest backupem. Snapshot to zapisany stan danych w danym momencie, ale przechowywany w tym samym systemie i zwykle zależny od oryginalnych bloków — jeśli padnie macierz, ktoś usunie wolumen albo ransomware przejmie serwer, snapshot zniknie razem z danymi. Backup to niezależna kopia w innym miejscu, z której odtworzysz system nawet wtedy, gdy oryginał już nie istnieje.

Oba mechanizmy są potrzebne, tylko do czego innego. Snapshot pozwala w kilka sekund cofnąć nieudaną aktualizację. Backup pozwala przeżyć pożar serwerowni, awarię dysków i atak. Poniżej wyjaśniam, skąd ta różnica wynika technicznie i jak wygląda w LVM, ZFS, Btrfs, VMware, Hyper-V, Proxmoksie i chmurze.

Snapshot vs backup – różnice w jednej tabeli

Najkrócej: snapshot odpowiada na pytanie „jak szybko cofnąć to, co właśnie zepsułem?”, a backup na pytanie „jak odzyskać dane, gdy wszystko inne zawiodło?”.

Jak działa snapshot i dlaczego zależy od oryginału

Snapshot powstaje w sekundach, bo niczego nie kopiuje. W chwili jego utworzenia system zamraża mapę bloków, a nowe zapisy obsługuje jedną z dwóch metod:

• Copy-on-write (CoW) — przed nadpisaniem bloku jego stara wersja jest kopiowana do obszaru snapshotu. Tak działają klasyczne snapshoty LVM.
• Redirect-on-write / zapis w nowym miejscu — nowe dane trafiają w nowe miejsce, a stare bloki zostają tam, gdzie były, i są wskazywane przez snapshot. Tak działają ZFS i Btrfs, a podobnie pliki różnicowe maszyn wirtualnych (-delta.vmdk w VMware, .avhdx w Hyper-V, qcow2).

W obu przypadkach snapshot zawiera tylko różnice albo wskaźniki do bloków, które fizycznie leżą na tym samym nośniku. Dlatego uszkodzenie puli dysków, pomyłkowe lvremove czy usunięcie maszyny wirtualnej z datastore’u zabiera snapshoty ze sobą.

Snapshot a spójność danych

Snapshot wykonany „na żywo” jest domyślnie spójny awaryjnie (crash-consistent), czyli wygląda tak, jakby serwer nagle stracił zasilanie. System plików zwykle się z tego podniesie, ale baza danych z niezapisanymi transakcjami może wymagać odtwarzania logów.

Żeby uzyskać kopię spójną aplikacyjnie, przed snapshotem trzeba „uciszyć” aplikację: w Windows robi to usługa VSS (więcej w artykule czym jest Volume Shadow Copy), w Linuksie fsfreeze lub agent gościa (np. QEMU Guest Agent), a w bazach danych — ich własne mechanizmy blokady lub zrzutu.

Snapshoty w praktyce: LVM, ZFS i Btrfs

LVM

Klasyczny snapshot LVM wymaga zarezerwowania miejsca na zmiany. Jeśli to miejsce się zapełni, snapshot staje się nieważny.

# snapshot woluminu root z 10 GB miejsca na zmiany
sudo lvcreate --size 10G --snapshot --name root_przed_upgrade /dev/vg0/root

# sprawdzenie zajętości snapshotu (kolumna Data%)
sudo lvs

# cofnięcie zmian: scalenie snapshotu z oryginałem (dla aktywnego roota po restarcie)
sudo lvconvert --merge /dev/vg0/root_przed_upgrade

# albo usunięcie snapshotu, gdy aktualizacja się udała
sudo lvremove /dev/vg0/root_przed_upgrade

Długo trzymany snapshot LVM spowalnia zapisy, bo każda zmiana oznacza dodatkowe kopiowanie bloku.

ZFS

W ZFS snapshoty są tanie i można ich mieć tysiące. Są dostępne tylko do odczytu w ukrytym katalogu .zfs/snapshot, z którego łatwo wyciągnąć pojedynczy plik.

zfs snapshot tank/dane@2026-09-26
zfs list -t snapshot
zfs rollback tank/dane@2026-09-26

Kluczowe jest polecenie zfs send. Wysyła ono snapshot (lub różnicę między dwoma snapshotami) na inny serwer — i dopiero to jest backup:

zfs send -i tank/dane@2026-09-25 tank/dane@2026-09-26 | ssh backup zfs receive -F kopie/dane

Btrfs

Btrfs tworzy snapshoty subwolumenów. Narzędzia takie jak Snapper (openSUSE) czy Timeshift (Linux Mint i inne) robią je automatycznie przed aktualizacją pakietów, co pozwala uruchomić system z poprzedniego stanu.

sudo btrfs subvolume snapshot -r /home /home/.snapshots/home-2026-09-26
sudo btrfs send /home/.snapshots/home-2026-09-26 | ssh backup "btrfs receive /kopie"

Tak samo jak w ZFS: snapshot na tym samym dysku chroni przed błędem, btrfs send na inny nośnik — przed awarią.

Snapshoty maszyn wirtualnych: VMware, Hyper-V, Proxmox

W wirtualizacji pomylenie snapshotu z backupem jest najczęstsze, bo panel pokazuje „punkty przywracania” jednym kliknięciem.

VMware vSphere / ESXi

Snapshot w VMware tworzy plik różnicowy, do którego trafiają wszystkie nowe zapisy. VMware w swoich zaleceniach podkreśla, że snapshoty nie są kopiami zapasowymi, nie powinny istnieć dłużej niż 24–72 godziny, a łańcuch powinien mieć najwyżej kilka pozycji (technicznie dozwolone jest 32). Stary snapshot może urosnąć do rozmiaru całego dysku, zapchać datastore i zatrzymać maszyny, a jego usunięcie (konsolidacja) trwa długo i obciąża macierz.

Hyper-V

Hyper-V nazywa snapshoty checkpointami. Od Windows Server 2016 domyślne są checkpointy produkcyjne, wykonywane z użyciem VSS w gościu Windows lub zamrożenia systemu plików w Linuksie, więc są spójne aplikacyjnie. Mimo to to nadal plik .avhdx obok dysku maszyny — przydatny przed aktualizacją, ale nie zamiast kopii.

Proxmox VE

Proxmox rozdziela te pojęcia bardzo wyraźnie, co dobrze ilustruje różnicę:

# snapshot – punkt powrotu na tym samym storage'u
qm snapshot 101 przed_aktualizacja
qm rollback 101 przed_aktualizacja
qm delsnapshot 101 przed_aktualizacja

# backup – pełna kopia na osobny storage (np. Proxmox Backup Server)
vzdump 101 --mode snapshot --storage pbs

Zwróć uwagę na --mode snapshot w vzdump: snapshot jest tu użyty tylko jako chwilowe źródło spójnych danych, które potem są kopiowane na inny storage. To wzorcowy przykład, jak snapshot i backup współpracują. Więcej o konfiguracji w poradnikach Proxmox – instalacja i konfiguracja oraz 10 najlepszych praktyk w Proxmox.

Snapshoty w chmurze – szczególny przypadek

W chmurze granica jest mniej ostra. Snapshot dysku EBS w AWS lub snapshot dysku zarządzanego w Azure jest przechowywany niezależnie od samego wolumenu — możesz usunąć dysk, a snapshot zostanie i odtworzysz z niego nowy wolumen. Pod tym względem przypomina backup.

Wciąż jednak leży na tym samym koncie, w tym samym regionie i podlega tym samym uprawnieniom. Napastnik lub skrypt z uprawnieniami administratora konta usunie go równie łatwo jak maszynę. Dlatego:

1. kopiuj snapshoty do innego regionu i najlepiej innego konta (subskrypcji),
2. używaj usług backupu z blokadą usuwania (np. AWS Backup Vault Lock, niezmienialne magazyny w Azure Backup),
3. ogranicz, kto może usuwać snapshoty i kopie.

Ważne: Snapshoty na serwerach plików i NAS-ach (np. migawki Btrfs na Synology czy ZFS w TrueNAS) dobrze chronią przed ransomware szyfrującym udostępnione foldery z komputera użytkownika. Nie chronią jednak, jeśli napastnik zdobędzie konto administratora samego NAS-a — wtedy może je po prostu usunąć.

Snapshot a ransomware

Ransomware w Windows bardzo często zaczyna od usunięcia kopii VSS poleceniem w rodzaju vssadmin delete shadows /all /quiet. Podobnie grupy atakujące środowiska wirtualne po przejęciu vCentera czy hypervisora kasują snapshoty i lokalne kopie, zanim zaszyfrują dyski maszyn.

To najlepiej pokazuje, czemu snapshot nie jest backupem: jest pod kontrolą tego samego systemu i tych samych kont, które atakujący przejmuje. Backup odporny na ransomware musi być od nich odseparowany — fizycznie (offline, taśma, odłączany dysk) albo logicznie (osobne poświadczenia, niezmienialność, brak dostępu z domeny produkcyjnej).

Jak połączyć snapshoty i backup w sensowną strategię

Dobry punkt wyjścia to zasada 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, z czego jedna poza siedzibą. Coraz częściej rozszerza się ją do 3-2-1-1-0 — dodatkowa kopia offline lub niezmienialna i zero błędów przy testowym odtworzeniu.

W praktyce wygląda to tak:

1. Snapshoty — automatycznie co godzinę lub co dzień, z krótką retencją (np. 24 godzinowe i 7 dziennych), plus ręczny snapshot przed każdą większą zmianą. Służą do szybkiego cofania.
2. Backup lokalny — codziennie na osobny serwer lub NAS (np. Proxmox Backup Server, Veeam, restic, Borg), z dłuższą retencją. Służy do szybkiego odtwarzania po awarii.
3. Kopia poza siedzibą — replikacja backupu do chmury lub drugiej lokalizacji, najlepiej z niezmienialnością.
4. Test odtworzenia — regularnie, przynajmniej raz na kwartał, odtwórz losowy serwer lub bazę w izolowanym środowisku. Backup, którego nikt nie odtwarzał, to tylko nadzieja.

Jeśli potrzebujesz pełnej kopii całego dysku fizycznego, np. przed wymianą na nowy, sprawdzi się obraz wykonany narzędziem takim jak Clonezilla — opisujemy to w poradniku jak sklonować dysk za pomocą Clonezilli.

Kiedy wystarczy sam snapshot, a kiedy potrzebny jest backup

Sam snapshot wystarczy, gdy chcesz zabezpieczyć się na krótko przed własnym błędem: aktualizacja systemu, zmiana konfiguracji, test nowej wersji aplikacji, eksperyment na maszynie wirtualnej. Po potwierdzeniu, że wszystko działa, usuń go.

Backup jest niezbędny zawsze, gdy dane mają jakąkolwiek wartość: serwery produkcyjne, bazy danych, pliki firmowe, a także domowy NAS ze zdjęciami. Jeżeli jedyną „kopią” Twoich danych jest snapshot na tym samym serwerze, to w praktyce nie masz kopii zapasowej.