Komunikat „backup wykonany poprawnie” potwierdza, że mechanizm utworzył kopię. Nie odpowiada jeszcze na ważniejsze pytanie: czy urząd potrafi z tej kopii odtworzyć wybraną usługę, w akceptowalnym czasie i z kontrolowaną utratą danych. Odpowiedź daje dopiero test zakończony protokołem.
Ten materiał nie powtarza ogólnego opisu strategii kopii ani definicji RTO i RPO. Jeżeli urząd dopiero ustala priorytety, punktem wyjścia jest artykuł o BIA, RTO/RPO i testach ciągłości działania. Poniżej skupiamy się na jednym artefakcie: protokole technicznego testu odtworzeniowego.
Co test ma naprawdę potwierdzić
Dobry test nie zaczyna się od polecenia „proszę coś przywrócić”. Najpierw trzeba zapisać hipotezę, którą urząd chce sprawdzić. Może ona brzmieć: „z zatwierdzonej kopii z poprzedniej doby odtworzymy bazę i aplikację testową, a właściciel usługi potwierdzi poprawność trzech wskazanych operacji”.
Zakres powinien odpowiadać na sześć pytań:
- która usługa publiczna lub wewnętrzna jest przedmiotem testu;
- jakie systemy, dane, konfiguracje, certyfikaty i zależności są potrzebne;
- z którego punktu w czasie ma pochodzić kopia;
- jaki czas odtworzenia i jaka utrata danych są akceptowane;
- kto technicznie odtwarza, a kto potwierdza działanie usługi;
- jakie warunki powodują przerwanie testu.
Na pierwszy test warto wybrać jedną ważną, ale możliwą do bezpiecznego sprawdzenia usługę. Nie trzeba od razu wyłączać produkcji. Odtworzenie do odseparowanego środowiska testowego pozwala sprawdzić kopię, instrukcję i kompetencje bez ryzykowania dostępności bieżącej pracy.
Role i warunki bezpieczeństwa
Przed rozpoczęciem trzeba wskazać prowadzącego test, wykonawcę technicznego, właściciela usługi oraz osobę zatwierdzającą wynik. Jeżeli część pracy wykonuje dostawca, jego udział i odpowiedzialność również powinny znaleźć się w protokole.
Test nie może naruszać dowodów z trwającego incydentu ani wprowadzać niezweryfikowanych danych do produkcji. W przypadku podejrzenia ataku pierwszeństwo ma uzgodniona procedura obsługi incydentu M06. Zwykłego testu nie należy mieszać z analizą powłamaniową.
Zasada praktyczna: przed startem zapisz zakres, punkt odtworzenia, środowisko docelowe i osoby uprawnione do decyzji. Jeśli któregoś z tych elementów brakuje, test jeszcze się nie rozpoczął.
Przebieg testu krok po kroku
1. Zamroź zakres i zanotuj stan początkowy
Zapisz nazwę usługi, wersję systemu, lokalizację kopii, datę jej wykonania, identyfikator zadania backupowego oraz oczekiwany punkt odtworzenia. Nie polegaj wyłącznie na zrzucie ekranu z komunikatem „sukces”. Protokół ma pozwolić innej osobie odtworzyć tok decyzji.
2. Uruchom pomiar czasu
Moment startu powinien być jednoznaczny: na przykład od wydania zatwierdzonej decyzji o odtworzeniu albo od rozpoczęcia pobierania kopii. Zanotuj osobno czas przygotowania środowiska, transferu danych, uruchomienia systemu i weryfikacji usługi. Dzięki temu urząd wie, gdzie rzeczywiście powstaje opóźnienie.
3. Odtwórz dane i konfigurację w kontrolowanym środowisku
Wykonawca pracuje według aktualnej instrukcji, zapisując odstępstwa i brakujące kroki. Jeżeli trzeba sięgać do wiedzy jednej konkretnej osoby, odzyskiwać niedostępne hasło albo szukać starej wersji instalatora, to nie jest drobna niedogodność. To wynik testu, który wymaga działania korygującego.
4. Sprawdź technikę i działanie usługi
Weryfikacja techniczna obejmuje integralność danych, uruchomienie usług, logi błędów, połączenia z zależnościami i wymagane zabezpieczenia. Następnie właściciel usługi wykonuje kilka wcześniej ustalonych operacji, na przykład wyszukanie sprawy, utworzenie rekordu testowego i wygenerowanie raportu. Sam ekran logowania nie jest dowodem odtworzenia usługi.
5. Zamknij test decyzją
Wynik powinien mieć jeden z trzech stanów: zaliczony, zaliczony warunkowo albo niezaliczony. Do każdego wyjątku przypisz właściciela, termin i sposób ponownego sprawdzenia. Protokół bez decyzji i działań korygujących jest tylko opisem zdarzenia.
Pięć dowodów, które powinny zostać po teście
- Zakres i źródło odtworzenia. Jaka usługa była sprawdzana, z której kopii i do jakiego środowiska.
- Oś czasu. Godzina rozpoczęcia, kamienie milowe, moment uzyskania gotowości technicznej i zakończenia weryfikacji.
- Wyniki kontroli. Lista sprawdzeń technicznych i operacji zaakceptowanych przez właściciela usługi.
- Wyjątki i ryzyka. Brakujące dane, ręczne obejścia, opóźnienia, nieaktualna instrukcja oraz zależności, których nie udało się uruchomić.
- Decyzja i działania korygujące. Podpis lub zatwierdzenie osób odpowiedzialnych, właściciele poprawek, terminy i data ponownego testu.
Minimalny układ protokołu
Dokument może być krótki, jeśli pozostaje jednoznaczny. W praktyce wystarczą następujące pola:
- identyfikator, data i scenariusz testu;
- usługa, systemy wspierające i właściciel usługi;
- RTO, RPO oraz dopuszczalny zakres testu;
- źródło kopii i parametry środowiska docelowego;
- uczestnicy wraz z rolami;
- przebieg z godzinami i załączonymi dowodami;
- wynik, wyjątki, działania korygujące i zatwierdzenie.
Jeżeli urząd nie ma jeszcze spójnej procedury, warto najpierw uporządkować różnicę między kopią, odtworzeniem danych i przywróceniem usługi w materiale „Backup to nie wszystko”. Sam protokół powinien być częścią szerszego procesu dostępnego w module M10 — Ciągłość działania IT.
Co zrobić, gdy test się nie uda
Niezaliczony test nie jest porażką zespołu. Jest bezpiecznie wykrytą luką. Najpierw zabezpiecz logi i zapis przebiegu, następnie określ przyczynę: uszkodzona kopia, brak konfiguracji, nieaktualna instrukcja, niedostępne poświadczenia, brak zależności albo zbyt długi transfer. Każda przyczyna wymaga innej poprawki.
Jeżeli wynik pokazuje, że urząd nie zna kolejności usług, właścicieli albo akceptowalnego przestoju, wróć do strony diagnostycznej „Nie mam planu na wypadek awarii lub ataku”. Kolejny test zaplanuj dopiero po zamknięciu najważniejszych działań korygujących.
Źródła i data weryfikacji
Stan źródeł zweryfikowano 21 lipca 2026 r. NIST w kontroli CP-4 wskazuje na potrzebę testowania planu, przeglądu wyników i uruchamiania działań korygujących. Materiał Gov.pl przypomina, że kopię trzeba okresowo sprawdzać przez rzeczywiste odzyskanie danych.