Test odtwarzania backupu – jak sprawdzić, czy kopia działa

Dlaczego udany backup nie oznacza udanego odtworzenia

Zielony status w konsoli oprogramowania backupowego mówi tylko, że zadanie się zakończyło. Nie mówi, czy dane da się przywrócić, czy są kompletne i ile czasu potrwa odtworzenie. W praktyce podczas pierwszego testu w firmach najczęściej wychodzą na jaw takie problemy:

• Brakujące dane – nowy udział sieciowy albo baza programu księgowego nigdy nie trafiły do harmonogramu kopii.
• Uszkodzone pliki kopii – błędy nośnika lub przerwane zadania, których nikt nie zauważył.
• Brak haseł i kluczy – kopia jest zaszyfrowana, a klucz szyfrujący był zapisany wyłącznie na serwerze, który właśnie uległ awarii.
• Niespójne bazy danych – kopia pliku bazy wykonana w trakcie pracy, bez zatrzymania usługi czy mechanizmu VSS.
• Nierealny czas odtworzenia – przywrócenie 2 TB z chmury przez łącze 100 Mb/s trwa kilka dni, a nie kilka godzin.

Jeśli nie masz jeszcze uporządkowanej strategii kopii, zacznij od naszego poradnika backup krok po kroku, a dopiero potem wróć do testowania.

Zanim zaczniesz: RTO, RPO i lista krytycznych systemów

Test ma sens tylko wtedy, gdy wiesz, co chcesz sprawdzić. Zanim cokolwiek przywrócisz, ustal z zarządem dwie wartości dla każdego ważnego systemu:

• RPO (Recovery Point Objective) – ile danych firma może stracić. RPO 24 h oznacza, że utrata pracy z całego dnia jest akceptowalna.
• RTO (Recovery Time Objective) – jak długo system może być niedostępny, zanim zacznie to realnie kosztować.

Następnie przygotuj krótką listę systemów i nadaj im priorytety. W typowej firmie z sektora MŚP wygląda to mniej więcej tak:

1. Program finansowo-księgowy i baza ERP.
2. Serwer plików z dokumentami projektowymi i umowami.
3. Kontroler domeny lub konfiguracja tożsamości.
4. Poczta i dane w chmurze Microsoft 365 lub Google Workspace.
5. Stacje robocze kluczowych pracowników.

Dla każdej pozycji zapisz, gdzie leży kopia, czym jest wykonywana i kto ma do niej dostęp. Bez tej listy test zamieni się w przypadkowe klikanie.

Rodzaje testów – od pojedynczego pliku po pełne odtworzenie

Nie każdy test musi oznaczać odtwarzanie całej serwerowni. Najlepiej stosować kilka poziomów, różniących się częstotliwością i nakładem pracy:

• Weryfikacja automatyczna – sprawdzanie sum kontrolnych i integralności kopii przez samo oprogramowanie backupowe. Szybka, ale nie potwierdza, że system się uruchomi.
• Przywrócenie pojedynczych plików – losowy dokument, folder działu, skrzynka pocztowa. Sprawdza dostęp do repozytorium i uprawnienia.
• Odtworzenie aplikacji – przywrócenie bazy danych do środowiska testowego i uruchomienie programu na tej kopii.
• Pełne odtworzenie serwera – uruchomienie maszyny wirtualnej lub serwera fizycznego z kopii w izolowanej sieci i zmierzenie czasu.
• Ćwiczenie disaster recovery – symulacja utraty całej lokalizacji, z udziałem osób decyzyjnych i procedurą komunikacji.

Wiele nowoczesnych narzędzi (Veeam, Proxmox Backup Server, Synology Active Backup) pozwala uruchomić maszynę wirtualną bezpośrednio z kopii, bez kopiowania danych. To ogromnie skraca czas testu i pozwala robić go znacznie częściej.

Test odtwarzania krok po kroku

Poniższa procedura sprawdzi się przy kwartalnym teście serwera plików lub aplikacji biznesowej:

1. Przygotuj izolowane środowisko – osobną sieć VLAN lub sieć wirtualną bez dostępu do produkcji. Przywrócony kontroler domeny czy serwer z tą samą nazwą w sieci produkcyjnej może narobić poważnych szkód.
2. Wybierz punkt przywracania – nie zawsze najnowszy. Raz na jakiś czas sięgnij do kopii sprzed miesiąca lub z archiwum offline, żeby sprawdzić także starsze nośniki.
3. Zmierz czas – zanotuj godzinę rozpoczęcia, zakończenia przywracania i moment, w którym system jest faktycznie gotowy do pracy. To jest Twoje rzeczywiste RTO.
4. Uruchom system i zweryfikuj działanie – czy usługi startują, czy baza się otwiera, czy aplikacja nie zgłasza błędów spójności.
5. Poproś użytkownika o sprawdzenie danych – księgowa najlepiej oceni, czy w programie są ostatnie dokumenty. Informatyk widzi pliki, użytkownik widzi, czy są prawidłowe.
6. Sprawdź datę ostatnich danych – porównaj ją z założonym RPO.
7. Posprzątaj – usuń środowisko testowe, aby nie zostawiać w sieci kopii danych osobowych bez kontroli.

Przy serwerach z systemem Linux warto dodatkowo sprawdzić uprawnienia i właścicieli plików po odtworzeniu – szczegóły konfiguracji kopii opisaliśmy w artykule backup serwera Linux krok po kroku.

Harmonogram i dokumentacja testów

Jednorazowy test daje spokój na kilka tygodni. Środowisko się zmienia: dochodzą nowe aplikacje, rosną wolumeny danych, zmieniają się hasła. Dlatego testy trzeba wpisać w kalendarz IT na stałe. Dobrym punktem wyjścia jest:

• co tydzień – przegląd raportów z zadań backupu i alertów,
• co miesiąc – przywrócenie losowych plików i jednej skrzynki pocztowej,
• co kwartał – pełne odtworzenie co najmniej jednego krytycznego serwera,
• raz w roku – ćwiczenie disaster recovery z udziałem zarządu.

Każdy test zakończ krótkim protokołem: data, zakres, użyta kopia, czas odtworzenia, wynik, wykryte problemy i działania naprawcze. Taki dokument przydaje się podczas audytu NIS2, kontroli RODO czy rozmowy z ubezpieczycielem polisy cyber – coraz więcej z nich pyta wprost o dowody testowania kopii.

Jeżeli w firmie brakuje czasu lub ludzi na regularne testy, można przekazać je zespołowi, który zajmuje się utrzymaniem serwerów – wtedy test odtwarzania staje się stałym elementem opieki, a nie zadaniem odkładanym na później.

Najczęstsze błędy i jak ich uniknąć

• Testowanie tylko łatwych rzeczy – przywrócenie jednego pliku Word niczego nie dowodzi w kwestii bazy SQL czy kontrolera domeny.
• Brak kopii offline lub niezmiennej – ransomware coraz częściej celuje w repozytoria backupu. Test powinien obejmować także kopię odizolowaną (immutable lub na nośniku odłączonym).
• Dokumentacja tylko w głowie administratora – procedura odtworzenia musi być spisana tak, aby wykonał ją ktoś inny, także przy niedostępnym serwerze.
• Klucze szyfrowania w jednym miejscu – przechowuj je w menedżerze haseł oraz w zabezpieczonej kopii papierowej poza siedzibą firmy.
• Ignorowanie wyników – test, który wykazał trzydniowe RTO przy założonych czterech godzinach, wymaga decyzji: lepszego łącza, lokalnej kopii lub zapasowego serwera.

Warto też połączyć backup z monitoringiem – alerty o nieudanych zadaniach powinny trafiać do osoby, która na nie zareaguje. Jak to zorganizować, opisujemy w poradniku o monitoringu serwerów i sieci w firmie.