Twój backup Proxmox nie działa, dopóki nie zrobisz test-restore

Kalkulator Umów konsultację

Najczęstsza rozmowa po awarii wygląda tak: „przecież mieliśmy backup, zadania świeciły na zielono". A potem okazuje się, że odtworzenie nie przechodzi, obejmuje nie te maszyny, albo przywraca bazę danych w niespójnym stanie. Zielony status zadania backupu to informacja, że kopia się wykonała – nie że da się z niej odtworzyć. To dwie różne rzeczy i mylenie ich kosztuje firmy najwięcej.

Proxmox Backup Server (PBS) to świetne narzędzie – deduplikacja, przyrostowe kopie, szyfrowanie, weryfikacja. Ale narzędzie samo w sobie nie daje niezawodności. Poniżej pokazujemy, co odróżnia „robimy backupy" od „mamy backup, na którym można polegać".

Weryfikacja to nie to samo co odtwarzalność

PBS ma mechanizm Verify – przelicza sumy kontrolne chunków i potwierdza, że dane w datastore nie uległy cichej korupcji (bit rot). To ważne i koniecznie włącz zadania Verify, najlepiej z rozsądnym harmonogramem (np. świeże backupy weryfikowane raz, potem okresowo).

Ale uwaga: Verify potwierdza tylko integralność danych na dysku PBS. Nie mówi nic o tym, czy:

  • maszyna po odtworzeniu w ogóle się uruchomi,
  • backup objął właściwe woluminy i dyski,
  • baza danych w środku jest spójna,
  • masz dokąd i na czym odtworzyć w dniu awarii.
  • Innymi słowy: Verify sprawdza kopię, test-restore sprawdza procedurę odzyskiwania. Potrzebujesz obu.

    Test-restore: jedyny dowód, że backup działa

    Backup uznajemy za działający dopiero wtedy, gdy regularnie coś z niego odtwarzamy i to działa. Minimalny, zdrowy zestaw:

  • Odtwarzanie plikowe (file-level restore). PBS pozwala wejść w backup maszyny i wyciągnąć pojedyncze pliki bez przywracania całej VM. Przećwicz to – to najczęstszy realny scenariusz („ktoś skasował katalog").
  • Pełne odtworzenie maszyny do środowiska testowego. Raz na jakiś czas odtwórz całą VM na odizolowany node/sieć (żeby nie zderzyć się w sieci z produkcją o tym samym IP/MAC) i sprawdź, czy wstaje, loguje się, a aplikacja odpowiada.
  • Test odtworzenia bazy danych. Dla baz (SQL, Postgres) sam plik to za mało – sprawdź, czy baza się podnosi i przechodzi kontrolę spójności. Tu kłania się qemu-guest-agent i fs-freeze (patrz niżej).
  • Ustal kadencję – np. file-restore testujemy miesięcznie, pełne odtworzenie kluczowej maszyny kwartalnie – i zapisuj wyniki. Test-restore, którego nikt nie robi, jest wart tyle co jego brak.

    Spójność aplikacji: agent i fs-freeze

    Backup działającej maszyny bez współpracy z systemem gościa to backup „crash-consistent" – jak wyciągnięcie wtyczki. Baza danych może się z tego podnieść, ale nie musi.

    Dlatego w każdej maszynie powinien działać qemu-guest-agent, a w Proxmox musi być włączony (Options → QEMU Guest Agent → Enabled). Wtedy przed snapshotem PBS wykonuje fs-freeze – zamraża system plików na ułamek sekundy, żeby kopia była spójna. Bez agenta backup leci w trybie „unmanaged" i przy bazach danych to realne ryzyko. (Jeśli świeżo migrowałeś maszyny z VMware, sprawdź to koniecznie – opisaliśmy ten problem w tekście o pułapkach migracji.)

    Retencja i prune: żeby nie zapełnić i nie zgubić

    Druga strona medalu to polityka przechowywania. Dwa błędy skrajne: trzymanie wszystkiego (datastore się zapełnia, backupy zaczynają padać) albo zbyt agresywne kasowanie (nie ma z czego odtworzyć sprzed tygodnia).

    PBS realizuje model GFS (Grandfather-Father-Son) przez ustawienia Prune: `keep-daily`, `keep-weekly`, `keep-monthly`, `keep-yearly`. Sensowny punkt startowy dla wielu firm:

  • `keep-daily 7` – ostatni tydzień dzień po dniu,
  • `keep-weekly 4` – ostatni miesiąc tydzień po tygodniu,
  • `keep-monthly 6` – pół roku wstecz,
  • `keep-yearly 1–3` – zależnie od wymogów.
  • Pamiętaj o dwóch rzeczach: prune tylko oznacza backupy do usunięcia – miejsce zwalnia dopiero `garbage collect` (zaplanuj GC regularnie), a deduplikacja PBS sprawia, że kolejne kopie zajmują dużo mniej, niż sugeruje ich liczba. Retencję ustawiaj pod wymóg biznesowy/prawny (RPO), nie „na oko".

    Zasada 3-2-1 i kopia odporna na ransomware

    Backup stojący na tym samym sprzęcie (albo w tej samej serwerowni) co produkcja nie chroni przed pożarem, kradzieżą ani – co dziś najważniejsze – ransomware, który celuje właśnie w kopie zapasowe. Stąd klasyczna zasada 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, jedna poza lokalizacją.

    W praktyce, na PBS:

  • Remote sync / drugi PBS w innej lokalizacji – zadanie Sync replikuje datastore na zdalny serwer. Od PBS 4.x doszła też obsługa magazynu S3 jako celu, co upraszcza kopię do chmury.
  • Kopia odporna na modyfikację (immutable / append-only). Konto synchronizujące na zdalnym PBS ustaw z uprawnieniami tylko do zapisu/odczytu, bez prawa usuwania – tak, aby zaszyfrowany produkcyjny host nie mógł skasować kopii offsite. To jedna z najważniejszych linii obrony przed ransomware.
  • Osobne poświadczenia. Zdalna kopia musi mieć inne hasła/klucze niż produkcja. Jeśli atakujący przejmie środowisko główne, nie może tymi samymi danymi dobrać się do kopii.
  • Taśma (LTO) – dla środowisk wymagających kopii całkowicie offline PBS wspiera backup na taśmę.

Zrobić samemu czy zlecić?

Włączenie zadań backupu i Verify to kwestia paru kliknięć – i śmiało zrób to sam. Trudniejsza – i ważniejsza – jest strategia: jakie RPO/RTO, jaka retencja pod wymóg prawny, gdzie stoi kopia offsite, jak jest zabezpieczona przed ransomware i czy ktokolwiek regularnie testuje odtwarzanie. To obszar, w którym najczęściej pomagamy klientom – bo backup to jedyny system IT, którego jakość poznajesz dopiero w najgorszym możliwym dniu.

Projektujemy i wdrażamy backup Proxmox po polsku: PBS, retencja, kopia offsite odporna na ransomware, procedury i testy odtwarzania. Jeśli nie masz pewności, czy Twój backup naprawdę zadziała – lepiej sprawdzić to teraz niż po awarii.

FAQ

Jak często testować odtwarzanie?

Odtwarzanie plikowe – minimum raz w miesiącu. Pełne odtworzenie kluczowej maszyny – kwartalnie. Po każdej większej zmianie w infrastrukturze – dodatkowo. I zawsze po wdrożeniu nowego systemu do backupu.

Czy Verify w PBS wystarczy zamiast test-restore?

Nie. Verify potwierdza integralność danych na dysku PBS, ale nie sprawdza, czy maszyna się uruchomi ani czy backup objął właściwy zakres. To uzupełniające się mechanizmy – potrzebujesz obu.

Czy PBS chroni przed ransomware?

Sam w sobie nie – chroni odpowiednia architektura: kopia offsite z osobnymi poświadczeniami i uprawnieniami bez prawa usuwania (append-only), ewentualnie taśma. Chodzi o to, by przejęcie produkcji nie oznaczało przejęcia kopii.

Ile kopii przechowywać?

Zależnie od wymogu (RPO i regulacji). Popularny punkt startowy: 7 dziennych, 4 tygodniowe, 6 miesięcznych. Dzięki deduplikacji PBS taki zestaw zajmuje mniej miejsca, niż się wydaje.

Podsumowanie

Backup to nie zadanie w harmonogramie – to udowodniona zdolność do odtworzenia. Włącz Verify, ale nie myl go z odtwarzalnością. Rób test-restore i zapisuj wyniki. Zadbaj o agenta i spójność. Ustaw retencję pod realny wymóg. I trzymaj jedną kopię poza zasięgiem ransomware.

Chcesz wycenić Proxmox Backup Server z subskrypcją? Sprawdź kalkulator lub stronę Proxmox Backup Server. Wolisz, żeby ktoś zaprojektował i przetestował z Tobą całą strategię backupu? Umów konsultację, napisz na proxmox@polsoft.pl albo zadzwoń 32 209 80 39 (pon.–pt. 8:00–16:00).

Co dalej?

Potrzebujesz pomocy z Proxmox?

Skontaktuj się z nami - pomożemy Ci we wdrożeniu, migracji i utrzymaniu infrastruktury Proxmox.

Skontaktuj się