Backup, którego nigdy nie przywróciliście, jest tylko obietnicą. Pokazujemy, jak zbudować piramidę testów restore: od pojedynczego pliku, przez pełną VM w izolowanej sieci, po drill utraty całej serwerowni.
Większość firm, z którymi rozmawiamy, ma backupy. Prawie żadna nie ma regularnie testowanych backupów. Zielony status w Proxmox Backup Server, zaliczona weryfikacja sum kontrolnych, powiadomienie "backup successful" na mailu: to wszystko mówi tylko tyle, że dane zostały zapisane i da się je odczytać z dysku. Nie mówi nic o tym, czy system z tych danych wstanie i czy aplikacja będzie działać.
Weryfikacja w PBS (verify job) porównuje sumy kontrolne chunków z tym, co zostało zapisane przy backupie. Wykryje bit rot na datastore, nie wykryje bazy danych zrzuconej w środku transakcji, brakującego dysku z danymi, którego nikt nie objął backupem, ani aplikacji, która po starcie nie może się połączyć z usługą stojącą na innej maszynie. Udany verify i udany restore aplikacji to dwie różne rzeczy. Dopiero ta druga jest celem całego ćwiczenia.
Dlatego jedyna uczciwa definicja działającego backupu brzmi: taki, z którego w mierzalnym czasie przywróciliście działającą aplikację. Wszystko poniżej tego progu to nadzieja, że w dniu awarii los będzie łaskawy. Jak zaprojektować sam backup zgodnie z zasadą 3-2-1, opisaliśmy w osobnym artykule o backupie 3-2-1 z PBS. Tutaj zajmujemy się tym, co dalej: testowaniem.
Zanim zaczniecie testować, ustalcie, co właściwie testujecie. Dwa parametry definiują całe disaster recovery:
RTO (Recovery Time Objective) to odpowiedź na pytanie: jak długo możecie stać? Jeśli sklep internetowy generuje przychód co godzinę, RTO liczone w dniach jest nie do przyjęcia. Jeśli to wewnętrzny system raportowy, dzień przestoju może nikogo nie zaboleć.
RPO (Recovery Point Objective) to odpowiedź na pytanie: ile danych możecie stracić? Backup raz na dobę oznacza RPO do 24 godzin: w najgorszym wypadku tracicie cały dzień zamówień, dokumentów, zapisów. Dla systemu ERP z fakturami to często za dużo, dla serwera plików z szablonami dokumentów zwykle w porządku.
Kluczowa obserwacja: każda aplikacja ma inne RTO i RPO. Nie ma jednego "firmowego" parametru. Baza produkcyjna może wymagać RPO liczonego w minutach (a więc replikacji albo częstych backupów przyrostowych), podczas gdy maszyna testowa deweloperów zniesie tygodniowy backup. Od spisania tych wymagań per aplikacja zaczynamy każde projektowanie backupu i DR, bo dopiero one mówią, jaka architektura jest potrzebna i ile powinna kosztować. Testy restore służą potem do jednego: sprawdzenia, czy deklarowane RTO i RPO są prawdziwe.
Testy układamy w piramidę: na dole te tanie i częste, na górze drogie i rzadkie. Każdy poziom sprawdza coś, czego niższy nie obejmuje.
Najprostszy i paradoksalnie najbliższy rzeczywistości. Zdecydowana większość realnych "awarii" to nie pożar serwerowni, tylko człowiek, który skasował katalog albo nadpisał plik. PBS pozwala podmontować backup VM i wyciągnąć z niego pojedyncze pliki (file restore) bez przywracania całej maszyny. Test polega na tym, że wybieracie losowy plik z losowej VM, odzyskujecie go z backupu i porównujecie zawartość z oryginałem.
Test trwa minuty i przy okazji uczy zespół obsługi narzędzia, którego będzie używał najczęściej. Jeśli file restore nie działa (np. przez nieobsługiwany system plików w gościu albo brak uprawnień), lepiej dowiedzieć się o tym teraz niż przy zdenerwowanym użytkowniku nad głową.
Przywracacie całą maszynę z backupu pod nowym ID, podpinacie ją do izolowanej sieci (bridge bez uplinku albo VLAN testowy bez routingu do produkcji) i uruchamiacie. Izolacja jest kluczowa raz: maszyna wstaje z produkcyjnym adresem IP i hostname, więc bez niej zrobicie konflikt adresów i duplikat usług w sieci.
Sprawdzacie trzy rzeczy: czy system w ogóle startuje, czy usługi (baza, serwer aplikacji, cron) wstają bez ręcznej interwencji i czy dane są aktualne, czyli zgodne z oczekiwanym RPO. Notujecie czas całej operacji, bo to wasz realny, zmierzony RTO dla pojedynczej maszyny. Jak dokładnie wygląda taki test u nas, opisaliśmy w case study z testu przywracania z PBS.
Pojedyncza VM to za mało, jeśli aplikacja składa się z frontendu, backendu, bazy i kolejki na osobnych maszynach. Test aplikacyjny przywraca cały zestaw do izolowanego środowiska i sprawdza, czy komponenty się widzą i czy aplikacja przechodzi podstawowy scenariusz biznesowy: logowanie, odczyt danych, zapis nowego rekordu.
Osobny punkt kontrolny to spójność transakcyjna baz danych. Backup obrazu VM robiony przez snapshot bez wsparcia agenta (qemu-guest-agent z fsfreeze) albo bez mechanizmów crash-consistent recovery bazy może dać obraz, z którego baza wstaje w trybie recovery, gubi ostatnie transakcje albo nie wstaje wcale. Dopiero test aplikacyjny to wykrywa, bo tylko on faktycznie odpytuje bazę o dane po restore.
Szczyt piramidy. Symulujecie scenariusz z runbooka: pada węzeł klastra albo cała lokalizacja, a zespół odtwarza środowisko według spisanej procedury, na sprzęcie zapasowym albo w drugiej lokalizacji. Drill robi się z zegarkiem w ręku i z jedną żelazną zasadą: wykonujemy wyłącznie to, co jest w runbooku. Każde miejsce, w którym ktoś musiał improwizować, sięgnąć do własnej pamięci albo zadzwonić do "tego jednego admina, który wie", trafia na listę znalezisk.
Wynikiem drilla są dwie rzeczy: zmierzony czas odtworzenia (realne RTO całego środowiska, nie pojedynczej VM) i lista znalezisk do poprawy w runbooku, konfiguracji lub architekturze. Drill, po którym nie ma żadnych znalezisk, zdarza się rzadko i zwykle oznacza, że scenariusz był za łatwy.
Częstotliwość dobieramy do kosztu testu i wagi systemu. Sensowny punkt startowy dla typowego środowiska:
| Poziom testu | Częstotliwość | Zakres |
|---|---|---|
| Test plikowy | Przy każdej okazji, minimum raz w miesiącu | Losowy plik z losowej VM, porównanie z oryginałem |
| Pełna VM | Co miesiąc | Rotacyjnie inna maszyna, żeby w ciągu roku przejść przez całe środowisko |
| Test aplikacyjny | Co kwartał | Systemy krytyczne: aplikacja + baza + zależności, weryfikacja spójności danych |
| DR drill | 1-2 razy w roku | Utrata węzła lub lokalizacji wg runbooka, pomiar czasu, lista znalezisk |
W ramach Proxmox Care robimy comiesięczny testowy restore i raportujemy wynik: co przywróciliśmy, ile to trwało i czy dane były kompletne. Klient dostaje dowód działania backupu, nie tylko zielony status z harmonogramu.
Runbook to procedura odtwarzania spisana tak, żeby mógł ją wykonać kompetentny inżynier, który nie zna waszego środowiska na pamięć. Minimalna zawartość:
Jedna zasada nadrzędna: runbook musi istnieć także poza infrastrukturą, którą opisuje. Runbook na wiki, która stoi na klastrze objętym awarią, jest bezużyteczny dokładnie wtedy, kiedy jest potrzebny. Kopia wydrukowana, na zaszyfrowanym nośniku poza serwerownią albo w niezależnej usłudze chmurowej: forma dowolna, byle dostępna przy zgaszonym klastrze.
Po kilkunastu drillach u klientów pewne wzorce się powtarzają. Prawie nigdy nie zawodzi sam mechanizm backupu, zawodzi wszystko dookoła.
Klucz szyfrowania backupu był tylko na zaszyfrowanym serwerze. Backupy w PBS zaszyfrowane po stronie klienta, wzorowo. Klucz szyfrowania: w katalogu na tym samym hoście, który właśnie symulowaliśmy jako utracony. Bez kopii klucza poza infrastrukturą cały backup jest bezwartościowy.
Restore działa, ale DNS wskazuje stary adres. Środowisko odtworzone w drugiej lokalizacji wstało poprawnie, tylko wszystkie rekordy DNS nadal kierowały użytkowników do martwej serwerowni. Nikt nie ujął aktualizacji DNS w procedurze, a TTL rekordów był ustawiony na dobę.
Nikt nie zna hasła do konsoli. Serwery mają IPMI, procedura zakłada wejście przez konsolę zdalną, a hasło ustawiał administrator, który odszedł dwa lata temu. Drill stanął na kwadrans w minucie trzeciej, na pierwszym kroku procedury.
Żadnego z tych problemów nie wykryje weryfikacja sum kontrolnych ani monitoring backupów. Wykrywa je wyłącznie drill, i to jest jego główna wartość: znaleziska kosztują godzinę wstydu na spotkaniu podsumowującym zamiast dni przestoju przy prawdziwej awarii. Przegląd dostępów i twardnienie samego klastra warto przy okazji zderzyć z naszą checklistą bezpieczeństwa Proxmox, a architekturę odporności na utratę węzła z artykułem o tym, ile węzłów powinien mieć klaster.
Nie. Weryfikacja w PBS sprawdza sumy kontrolne chunków, czyli to, że backup nie uległ uszkodzeniu na dysku. Nie sprawdza, czy system z tego backupu wstanie, czy baza danych jest spójna transakcyjnie i czy aplikacja działa. To dwa różne pytania: weryfikacja mówi, że dane da się odczytać, test restore mówi, że da się na nich pracować. Potrzebujecie obu.
Przywracajcie VM pod nowym ID do izolowanej sieci: osobny bridge bez uplinku albo VLAN testowy bez routingu do produkcji. Maszyna wstaje z tym samym adresem IP i hostname co produkcyjna, ale nie widzi jej w sieci, więc nie ma konfliktu adresów ani duplikatów usług. Po weryfikacji usług i danych testową VM się kasuje. Cała operacja nie dotyka produkcji, więc można ją robić w godzinach pracy.
W ramach Proxmox Care (od 2 500 zł/mies.) co miesiąc wykonujemy testowy restore z waszych backupów i raportujemy wynik: co przywróciliśmy, ile trwało, czy dane były kompletne. Do tego monitoring, aktualizacje i wsparcie inżynierów, którzy utrzymują własny klaster produkcyjny.
Zapytaj o Proxmox Care