Paweł BurzyńskiProxmox & infrastruktura
← Wszystkie artykuły

Snapshoty ZFS i replikacja w Proxmox — zabezpieczenie VM w kilka minut

· 3 min czytania · Paweł Burzyński
ProxmoxZFSReplikacjaDR

Backup z vzdump robi się raz dziennie i odtwarza w kwadrans. Snapshot ZFS robi się w sekundę, a replikacja ZFS co 15 minut trzyma gotową kopię dysku VM na drugim węźle. To dwa różne narzędzia i dobrze mieć oba. Pokażę, jak je ustawić bez niespodzianek.

Warunek wstępny: dyski VM na ZFS

Replikacja wbudowana w Proxmox działa wyłącznie na storage typu ZFS (zwykle local-zfs, pula rpool). Sprawdź, gdzie leżą dyski maszyny:

qm config 100 | grep -E '^(scsi|virtio|sata|ide)[0-9]'
pvesm status
zfs list -r rpool/data

Jeśli widzisz local-zfs:vm-100-disk-0, jesteś w domu. Dysk na local-lvm lub na katalogu NFS trzeba najpierw przenieść (Hardware → Disk → Move Storage, albo qm move-disk 100 scsi0 local-zfs).

Snapshot VM z poziomu Proxmox

Przed aktualizacją systemu w maszynie rób snapshot przez qm, nie przez gołe zfs. Proxmox zapisze wtedy też konfigurację VM i opcjonalnie stan RAM:

# snapshot samego dysku (szybki, VM działa dalej)
qm snapshot 100 przed-upgrade --description "Debian 12 -> 13"

# snapshot z pamięcią RAM (po rollbacku VM wraca "żywa", tam gdzie była)
qm snapshot 100 przed-upgrade --vmstate 1

qm listsnapshot 100

Coś poszło nie tak? Powrót trwa sekundy:

qm rollback 100 przed-upgrade
qm start 100

Po udanej zmianie snapshot usuń. Każdy snapshot trzyma stare bloki, więc zajęte miejsce rośnie z każdym zapisem w VM:

qm delsnapshot 100 przed-upgrade
zfs list -o name,used,usedbysnapshots -r rpool/data

Kolumna usedbysnapshots pokazuje, ile realnie kosztują zapomniane snapshoty. Na produkcji trzymaj je godziny, nie tygodnie.

Snapshot gołym ZFS — kiedy ma sens

Gołe zfs snapshot przydaje się do szybkich kopii poza wiedzą Proxmox, np. przed migracją danych w kontenerze albo do skryptowania:

zfs snapshot rpool/data/vm-100-disk-0@reczny-2026-10-05
zfs list -t snapshot -r rpool/data/vm-100-disk-0
zfs rollback rpool/data/vm-100-disk-0@reczny-2026-10-05

Uwaga: taki snapshot nie jest widoczny w GUI i qm rollback go nie zna. Rollback gołym zfs rób tylko przy zatrzymanej VM, inaczej system gościa dostanie dysk, który zmienił się „pod nim".

Replikacja między węzłami (pvesr)

Replikacja wymaga klastra Proxmox (minimum 2 węzły) i storage ZFS o tej samej nazwie na obu hostach. Nie potrzebujesz wspólnego storage ani Ceph. Mechanizm: Proxmox robi snapshot, wysyła zfs send przyrostowo na drugi węzeł i tam utrzymuje aktualną kopię dysku.

Utworzenie zadania z linii poleceń (ID zadania to <vmid>-<numer>):

# VM 100 -> węzeł pve2, co 15 minut, limit 50 MB/s
pvesr create-local-job 100-0 pve2 --schedule '*/15' --rate 50

# codziennie o 2:30 w dni robocze
pvesr create-local-job 101-0 pve2 --schedule 'mon..fri 02:30'

pvesr list
pvesr status

Pierwsze uruchomienie przesyła cały dysk, kolejne tylko różnice. Możesz wymusić start od razu, zamiast czekać na harmonogram:

pvesr run --id 100-0 --verbose

Na węźle docelowym pojawi się dataset rpool/data/vm-100-disk-0 ze snapshotami @__replicate_100-0_<timestamp>__. Nie usuwaj ich ręcznie — Proxmox sam rotuje je przy kolejnym przebiegu.

W GUI to samo znajdziesz w Datacenter → Replication, a stan ostatniego przebiegu na zakładce Replication przy każdej VM.

Co daje replikacja w praktyce

Szybka migracja. Przy qm migrate 100 pve2 --online Proxmox przesyła tylko bloki zmienione od ostatniej replikacji, zamiast całego dysku. Migracja 200 GB maszyny skraca się z godziny do minut.

Ręczny failover po awarii węzła. Węzeł pve1 padł, VM 100 nie wstaje. Na działającym pve2 przenieś konfigurację i uruchom maszynę z replikowanego dysku:

# na pve2, gdy pve1 jest offline
mv /etc/pve/nodes/pve1/qemu-server/100.conf /etc/pve/nodes/pve2/qemu-server/
qm start 100

Tracisz dane z okresu od ostatniej replikacji (przy */15 najwyżej 15 minut). Dla większości usług to akceptowalne, dla bazy transakcyjnej — ustal to z właścicielem systemu wcześniej, nie podczas awarii.

Po przywróceniu pve1 kierunek replikacji odwróć (edytuj zadanie, cel = pve1), inaczej stare dane z pve1 nie zostaną nigdy nadpisane, a zadanie będzie zgłaszać błędy.

Replikacja poza klaster — zfs send/recv

Chcesz kopię na maszynie, która nie jest w klastrze (np. serwer w innej lokalizacji)? Wystarczy SSH i ZFS po drugiej stronie:

# pełna kopia
zfs snapshot rpool/data/vm-100-disk-0@base
zfs send rpool/data/vm-100-disk-0@base | ssh backup-host zfs recv -F tank/replika/vm-100-disk-0

# przyrost (po kolejnym snapshocie)
zfs snapshot rpool/data/vm-100-disk-0@inc1
zfs send -i @base rpool/data/vm-100-disk-0@inc1 | ssh backup-host zfs recv tank/replika/vm-100-disk-0

Do automatyzacji użyj sanoid/syncoid (pakiet w Debianie) — ogarnia rotację snapshotów i przyrosty za Ciebie.

Checklista na koniec