Test przywracania: sprawdzamy własne backupy, zanim zrobi to awaria

Backup, który nikt nigdy nie przywrócił, to hipoteza

Weryfikacja backupu to nie to samo co udany restore. PBS ma wbudowany mechanizm verify, który sprawdza sumy kontrolne chunków w datastore, i my go oczywiście używamy. Ale verify odpowiada tylko na pytanie, czy dane na dysku backupowym są takie same, jak w momencie zapisu. Nie odpowiada na pytanie, czy z tych danych da się odtworzyć działającą maszynę, na której startują usługi i aplikacja widzi swoje dane.

Dlatego na naszej własnej infrastrukturze (8 węzłów Proxmox, na których działa hosting IQHost, plus dwa serwery Proxmox Backup Server w dwóch lokalizacjach, z ponad 100 TB przestrzeni) prowadzimy comiesięczny test przywracania. Wybieramy jedną maszynę, przywracamy ją z backupu i patrzymy, czy naprawdę wstaje. Nie w teorii, nie na podstawie logów zadania backupowego, tylko fizycznie: konsola, login, usługi, dane.

Ten wpis opisuje dokładnie, jak to robimy. Procedura jest prosta i możecie ją wdrożyć u siebie choćby w przyszłym tygodniu. Jeśli wolicie, żeby robił to ktoś za was, taki test jest częścią naszej usługi administracji i utrzymania Proxmox.

Procedura krok po kroku

1. Wybór maszyny. Każdego miesiąca inna VM, rotacyjnie. Dzięki temu w ciągu roku przez test przechodzi przekrój środowiska: bazy danych, serwery aplikacyjne, maszyny pomocnicze. Testowanie w kółko tej samej, najłatwiejszej VM daje fałszywy spokój.
2. Restore z PBS do izolowanego VLAN-u testowego. Maszyna wraca z tymi samymi adresami IP co produkcja, więc nie może się z nią zderzyć. Odtwarzamy ją do wydzielonego VLAN-u bez routingu do sieci produkcyjnej. Zero ryzyka konfliktu IP, duplikatów ARP czy aplikacji, która po starcie zacznie pisać do produkcyjnej bazy.
3. Start i weryfikacja. System operacyjny wstaje, usługi startują same, dane są spójne, w logach nie ma błędów startowych. Sprawdzamy to ręcznie z konsoli, nie zdalnie skryptem, bo skrypt nie zauważy, że baza wstała w trybie recovery albo że usługa czeka na wpisanie passphrase.
4. Odczyt najnowszych danych. Otwieramy najświeższe rekordy, pliki lub wpisy, jakie maszyna powinna mieć z ostatniego backupu. To potwierdza, że backup jest aktualny, a nie tylko poprawny technicznie. Zdarza się, że zadanie backupowe działa, ale omija wolumen dodany po jego konfiguracji.
5. Pomiar czasu całości. Od decyzji o przywróceniu do momentu, w którym maszyna jest zweryfikowana jako działająca. To nasz realny RTO dla tej klasy maszyny, a nie liczba z dokumentu.
6. Wpis do rejestru testów. Co przywracaliśmy, kiedy, jaki był wynik, ile trwało, jakie były uwagi. Rejestr jest nudny dokładnie do momentu, w którym audytor, ubezpieczyciel albo zarząd zapyta, skąd wiemy, że backupy działają.
7. Kasacja środowiska testowego. Przywrócona maszyna i jej dyski znikają. Nic nie zostaje, nic nie zjada przestrzeni na storage i nikt za pół roku nie znajdzie zapomnianej kopii produkcyjnych danych w testowym VLAN-ie.

Dlaczego mierzymy czas, a nie chwalimy się minutami

Celowo nie podajemy tu konkretnych czasów restore. Zależą od rozmiaru dysków maszyny, obciążenia storage i tego, czy PBS akurat robi garbage collection. Wynik dla naszej infrastruktury nic wam nie powie o waszej.

Ważne jest co innego: czas jest zmierzony i porównywalny między miesiącami. Jeśli restore tej samej klasy maszyny z miesiąca na miesiąc trwa coraz dłużej, to sygnał: rośnie fragmentacja datastore, storage się zapełnia, sieć backupowa jest wysycona albo maszyna urosła bardziej, niż ktokolwiek zauważył. Trend wyłapany w teście to problem rozwiązany w spokojny wtorek. Trend wyłapany podczas awarii to noc, którą wszyscy zapamiętają.

Jak zaprojektować cały łańcuch kopii, z którego takie testy się robi, opisujemy w artykule o strategii backupu 3-2-1 na Proxmox Backup Server, a szerzej o metodyce testów w tekście o testach restore i disaster recovery.

To samo robimy u klientów

Comiesięczny testowy restore z raportem jest stałym elementem Proxmox Care, naszej usługi utrzymania. Klient co miesiąc dostaje potwierdzenie na piśmie: ta maszyna została przywrócona, wstała, dane były aktualne, całość trwała tyle. Jeśli coś nie zadziałało, naprawiamy przyczynę i test powtarzamy.

Dla firm, które mają już backup, ale nikt go nigdy nie przywracał, dobrym punktem startu jest też Proxmox Health Check: przeglądamy konfigurację klastra i backupów i wskazujemy, co wymaga uwagi, zanim zrobi to awaria. A jeśli dopiero budujecie warstwę backupu, zacznijcie od wdrożenia Proxmox Backup Server z deduplikacją i testami restore od pierwszego miesiąca.