Test odtwarzania backupu. Jak sprawdzić,
czy kopia naprawdę działa?

Backup wykonuje się codziennie. Raport przychodzi rano. Status: sukces. Czy to oznacza, że po awarii odzyskasz dane?

Nie.

Oznacza tylko, że zadanie backupowe zakończyło się zgodnie z logiką systemu. Dopiero test odtwarzania pokazuje, czy kopia jest kompletna, czy można ją odczytać, czy system po restore rzeczywiście się uruchomi i ile potrwa powrót firmy do pracy.

Backup bez testu restore jest założeniem. Nie dowodem.

Dlaczego zielony status backupu nie wystarczy?

System backupowy może poprawnie zapisać wszystko, co zostało mu zlecone. Problem w tym, że konfiguracja mogła być błędna już na początku. Przykładowo:

Z punktu widzenia systemu backup zakończył się poprawnie. Z punktu widzenia Disaster Recovery firma może nadal nie mieć z czego się odtworzyć.

Najważniejsze pytanie brzmi: czy potrafimy wrócić do pracy?

Celem backupu nie jest posiadanie pliku .bak, snapshotu albo kopii VM. Celem jest odzyskanie usługi biznesowej. Dlatego test powinien odpowiadać kolejno na pytania:

1. 1 Czy kopia istnieje?
2. 2 Czy jest integralna?
3. 3 Czy można ją odczytać?
4. 4 Czy można z niej odtworzyć system?
5. 5 Czy system po restore się uruchamia?
6. 6 Czy aplikacja działa?
7. 7 Czy dane są kompletne?
8. 8 Czy integracje działają?
9. 9 Ile trwa cały proces?
10. 10 Czy mieścimy się w założonym RTO i RPO?

Dopiero ostatnie pytania pokazują realną wartość strategii backupowej.

Weryfikacja backupu a test restore

To dwa różne procesy.

Przykładowo Proxmox Backup Server umożliwia tworzenie cyklicznych Verification Jobs sprawdzających integralność snapshotów backupowych. Proxmox rekomenduje regularne uruchamianie takich zadań. To bardzo ważna warstwa ochrony, ale nadal nie odpowiada na pytanie: czy Windows Server wystartuje i czy ERP będzie działał?

Restore oznacza rzeczywiste przywrócenie danych - pliku, katalogu, bazy danych, maszyny wirtualnej, całej aplikacji lub pełnego środowiska. Najwyższy poziom pewności daje dopiero uruchomienie odtworzonego systemu w izolowanym środowisku oraz sprawdzenie jego funkcji.

Veeam realizuje taki model między innymi poprzez SureBackup, który może uruchamiać maszyny z backupu w Virtual Lab i wykonywać testy odzyskiwania.

Cztery poziomy testowania backupu

Nie każdy test musi oznaczać symulację pożaru całej serwerowni. W praktyce warto stosować kilka poziomów.

Jeżeli backup zwykle zajmuje 800 GB, a dziś ma 70 GB, status "success" nie powinien uspokajać.

W SQL Server można wykorzystać między innymi RESTORE VERIFYONLY, które sprawdza, czy zestaw backupowy jest kompletny i możliwy do odczytania. Microsoft wyraźnie zaznacza jednak, że polecenie nie wykonuje pełnego restore i nie weryfikuje całej logicznej struktury danych.

VERIFYONLY jest przydatne, ale nie zastępuje testowego odtworzenia bazy.

Na poziomie 4, dla ERP, dobry test wygląda przykładowo tak:

Dopiero wtedy można powiedzieć: tak, potrafimy odzyskać ERP.

Test plików

Najprostszy scenariusz. Losowo wybieramy kilka danych z różnych punktów retencji - na przykład plik z wczoraj, plik sprzed tygodnia i plik sprzed miesiąca. Następnie przywracamy je do innego katalogu i sprawdzamy:

• › Czy można je otworzyć
• › Czy mają poprawną zawartość
• › Czy zachowały wymagane metadane

Warto celowo wybierać różne typy danych. Nie testować przez trzy lata tego samego pliku PDF.

Test maszyny wirtualnej

W środowisku Proxmox lub VMware jednym z najważniejszych testów jest pełne odtworzenie VM. Maszyna powinna zostać uruchomiona w izolowanej sieci. To bardzo ważne - nie chcemy sytuacji, w której testowo przywrócony:

zacznie komunikować się z produkcją. Środowisko testowe powinno więc posiadać:

Po uruchomieniu sprawdzamy boot systemu, system plików, usługi, logi, sieć i aplikacje.

Test SQL Server

Dla ERP oraz innych aplikacji biznesowych test bazy jest szczególnie ważny. Sam fakt posiadania .bak nie oznacza jeszcze, że firma potrafi odbudować bazę. Dobry test obejmuje:

1. 1 Restore pełnego backupu.
2. 2 Restore differential, jeżeli jest stosowany.
3. 3 Restore logów transakcyjnych.
4. 4 Odtworzenie do określonego punktu w czasie.
5. 5 Uruchomienie kontroli spójności.
6. 6 Podłączenie aplikacji testowej.
7. 7 Weryfikację danych.

To pozwala sprawdzić nie tylko pełny backup, ale również cały łańcuch wymagany dla Point-in-Time Recovery. Więcej o architekturze SQL Server dla ERP piszemy w artykule dlaczego SQL Server zwalnia.

Test PostgreSQL i MySQL

Ta sama zasada dotyczy innych baz. Nie wystarczy wiedzieć, że dump powstaje. Trzeba go okresowo odtworzyć, uruchomić bazę, wykonać zapytania, sprawdzić spójność oraz zweryfikować użytkowników i uprawnienia.

W przypadku replikacji lub backupów binarnych warto również przetestować konkretny scenariusz odzyskiwania, który firma zakłada w dokumentacji.

Nie testuj restore na produkcji

To wydaje się oczywiste, ale warto powiedzieć to wprost.

Testujemy w odseparowanym środowisku. Dzięki temu możemy uruchomić starszą kopię, pracować na niej, zmieniać konfigurację, wykonywać kontrole i symulować awarie bez ryzyka wpływu na system produkcyjny.

RTO. Zegarek powinien ruszyć razem z testem

Jednym z największych błędów jest testowanie wyłącznie poprawności danych.

Backup działa. VM się odtworzyła. ERP się uruchomił. Sukces? Może.

Jeżeli zajęło to 17 godzin, a firma deklaruje RTO 2 godziny, strategia nie spełnia wymagań.

Dlatego podczas testu zapisujemy czas:

RTO powinno być zmierzone, a nie wpisane do dokumentu na podstawie przypuszczenia.

RPO też trzeba zweryfikować

RPO odpowiada na pytanie: ile danych stracimy? Załóżmy, że firma deklaruje RPO wynoszące 15 minut. Podczas testu okazuje się, że pełny backup wykonywany jest raz dziennie, a logi transakcyjne kopiowane są co godzinę.

Rzeczywiste RPO nie wynosi 15 minut. Dlatego test powinien sprawdzać również wiek dostępnego punktu przywracania.

Backup off-site również trzeba testować

To bardzo ważne. Firma może regularnie testować lokalny backup i nadal nie wiedzieć, czy zadziała Disaster Recovery. Dlatego okresowo warto odtworzyć dane właśnie z:

Więcej o projektowaniu takiej kopii piszemy w artykule backup off-site - gdzie trzymać drugą kopię danych firmy.

Testuj również starsze punkty restore

Bardzo częsty błąd polega na testowaniu tylko najnowszej kopii. To za mało. Ransomware może zostać wykryte po kilku tygodniach. Błąd księgowy może wyjść na jaw po miesiącu. Uszkodzenie danych może zostać zauważone znacznie później.

Dlatego warto testować również losowo wybrane starsze punkty przywracania.

Jak często wykonywać testy?

Nie istnieje jedna częstotliwość dobra dla każdego środowiska. Dobrym punktem wyjścia może być:

Dla systemów szczególnie krytycznych testy powinny odbywać się częściej. Nie warto jednak sztywno kopiować tabeli - częstotliwość powinna wynikać z krytyczności systemu, częstotliwości zmian, RTO, RPO i ryzyka biznesowego.

Kiedy wykonać dodatkowy test?

Niezależnie od harmonogramu test warto wykonać po istotnej zmianie. Na przykład po:

Infrastruktura się zmieniła. Procedura restore również mogła się zmienić.

Dokumentacja testu

Każdy test powinien zostawić po sobie coś więcej niż wiadomość "sprawdzone, działa". Raport powinien zawierać:

Przy kolejnym teście można wtedy zobaczyć, czy sytuacja się poprawiła.

Test powinien wykonać ktoś inny niż autor backupu

To bardzo dobra praktyka. Jeżeli cały proces zna tylko jedna osoba, podczas awarii firma nadal posiada pojedynczy punkt zależności. Od czasu do czasu procedurę powinien wykonać administrator, który nie konfigurował systemu backupowego. Dostaje dokumentację, dostęp i scenariusz - i próbuje odzyskać system.

Co powinno wydarzyć się po nieudanym teście?

Nieudany test backupu to dobra wiadomość. Naprawdę. Znacznie lepiej odkryć problem podczas zaplanowanego ćwiczenia niż podczas ransomware. Po wykryciu problemu:

1. 1 Określamy przyczynę.
2. 2 Poprawiamy konfigurację.
3. 3 Aktualizujemy dokumentację.
4. 4 Wykonujemy nowy backup.
5. 5 Ponawiamy test.

Test kończy się dopiero wtedy, gdy restore rzeczywiście działa.

Najczęstsze błędy

Automatyzacja testów

Część testów można automatyzować. Przykładowo Veeam SureBackup pozwala uruchamiać maszyny z backupu w izolowanym Virtual Lab oraz wykonywać testy takie jak heartbeat, ping i skrypty aplikacyjne. Proxmox Backup Server pozwala natomiast cyklicznie weryfikować integralność przechowywanych snapshotów.

Automatyzacja jest bardzo wartościowa. Nie powinna jednak całkowicie zastępować okresowego testu biznesowego. System może potwierdzić:

I to właśnie ten drugi test naprawdę interesuje firmę.

Jak testujemy backup w PRO-Admin?

Nie ograniczamy się do sprawdzania czerwonych i zielonych statusów. W zależności od środowiska weryfikujemy:

Dla systemów krytycznych możemy przygotować cykliczny plan testów. Przykładowo:

Dzięki temu pytanie:

FAQ - test odtwarzania backupu

Podsumowanie

Największym błędem w backupie jest przekonanie: "robimy kopię codziennie, więc jesteśmy bezpieczni".

Bez regularnych testów nie wiemy:

Dlatego test restore nie powinien być traktowany jako dodatkowa funkcja systemu backupowego. To część samego procesu backupu.

Backup jest zakończony dopiero wtedy, gdy wiemy, że można go skutecznie odtworzyć.