Disaster Recovery Plan — jak stworzyć plan odtwarzania krok po kroku

Według statystyk FEMA, 40% małych firm, które doświadczą poważnej awarii IT bez planu odtwarzania, nigdy nie wznawia działalności. Kolejne 25% upada w ciągu roku. To nie abstrakcyjne liczby — dotyczą również firm we Wrocławiu i na Dolnym Śląsku, które każdego dnia narażone są na awarie sprzętu, ataki ransomware, błędy ludzkie czy klęski żywiołowe. Disaster Recovery Plan (DRP) to dokument, który określa, jak szybko i w jakiej kolejności odtworzyć krytyczne systemy IT po awarii. W tym artykule przeprowadzimy Cię przez cały proces tworzenia DRP — od inwentaryzacji zasobów, przez analizę ryzyka, aż po testowanie i aktualizację planu.

Czym jest Disaster Recovery Plan?

Disaster Recovery Plan (plan odtwarzania po awarii) to formalny dokument opisujący procedury przywracania systemów IT do działania po zdarzeniu, które spowodowało ich niedostępność. DRP odpowiada na kluczowe pytania: co odtwarzamy, w jakiej kolejności, jak szybko i kto za to odpowiada.

DRP vs BCP — czym się różnią?

DRP jest często mylony z Business Continuity Plan (BCP), ale to dwa różne dokumenty:

• DRP (Disaster Recovery Plan) — koncentruje się na odtworzeniu infrastruktury IT: serwerów, baz danych, aplikacji, sieci, kopii zapasowych. To plan techniczny
• BCP (Business Continuity Plan) — obejmuje ciągłość działania całej organizacji: procesy biznesowe, komunikację z klientami, logistykę, zasoby ludzkie. DRP jest częścią BCP

Nawet jeśli Twoja firma nie ma formalnego BCP, sam DRP już znacząco zwiększa szanse na przetrwanie poważnej awarii.

Kiedy DRP jest niezbędny?

• Firma zależy od systemów IT — ERP, CRM, poczta, systemy produkcyjne, e-commerce
• Przetwarzasz dane osobowe — RODO wymaga zabezpieczenia danych, a NIS2 nakłada obowiązek posiadania planów ciągłości
• Przestój kosztuje pieniądze — jeśli godzina bez IT oznacza utracone przychody, DRP to inwestycja, nie koszt
• Klienci oczekują niezawodności — kontrahenci B2B coraz częściej wymagają udokumentowanego DRP w procesie kwalifikacji dostawców

Krok 1 — Inwentaryzacja zasobów krytycznych

Nie da się odtworzyć czegoś, czego nie zinwentaryzowano. Pierwszy krok to stworzenie kompletnej listy zasobów IT z oceną ich krytyczności.

Co inwentaryzujemy?

• Serwery fizyczne i wirtualne — nazwy, role (AD, poczta, ERP, pliki), lokalizacja, konfiguracja sprzętowa
• Bazy danych — silnik (MS SQL, PostgreSQL, MySQL), rozmiar, częstotliwość zmian, powiązania z aplikacjami
• Aplikacje biznesowe — ERP, CRM, systemy produkcyjne, e-commerce, narzędzia wewnętrzne
• Usługi chmurowe — Microsoft 365, Google Workspace, AWS, Azure — co jest w chmurze, a co on-premise
• Infrastruktura sieciowa — routery, switche, firewalle, VPN, adresy IP, konfiguracje
• Dane użytkowników — dyski sieciowe, profile, ustawienia, certyfikaty, klucze SSH

Klasyfikacja krytyczności

Każdy zasób klasyfikujemy na 3 poziomy:

• Krytyczny (Tier 1) — bez niego firma nie może działać: serwer ERP, baza danych produkcyjna, poczta, Active Directory
• Ważny (Tier 2) — znacząco wpływa na produktywność: system CRM, dyski sieciowe, drukowanie, VPN
• Pomocniczy (Tier 3) — komfort pracy, ale firma może funkcjonować bez niego: intranet, system rezerwacji sal, archiwum

Krok 2 — Analiza ryzyka i wpływu na biznes (BIA)

Business Impact Analysis (BIA) to proces identyfikacji zagrożeń i oszacowania ich wpływu na działalność firmy. BIA odpowiada na pytanie: „co się stanie, jeśli ten system będzie niedostępny przez X godzin/dni?"

Identyfikacja zagrożeń

• Awaria sprzętu — dysk, zasilacz, macierz RAID, UPS. Prawdopodobieństwo: wysokie. Wpływ: zależny od redundancji
• Atak ransomware — szyfrowanie danych, wymuszenie okupu. Prawdopodobieństwo: średnie-wysokie. Wpływ: krytyczny
• Błąd ludzki — przypadkowe usunięcie, nadpisanie, błędna konfiguracja. Prawdopodobieństwo: wysokie. Wpływ: zmienny
• Awaria zasilania — przerwa w dostawie prądu, przepięcia. Prawdopodobieństwo: średnie. Wpływ: zależny od UPS/generator
• Klęska żywiołowa — powódź (istotne dla Wrocławia!), pożar, burza. Prawdopodobieństwo: niskie. Wpływ: katastrofalny
• Awaria dostawcy chmury — niedostępność Azure/AWS/Google. Prawdopodobieństwo: niskie. Wpływ: zależny od zależności

Macierz ryzyka

Dla każdego zagrożenia określamy prawdopodobieństwo (niskie/średnie/wysokie) i wpływ (niski/średni/wysoki/krytyczny). Zagrożenia o wysokim prawdopodobieństwie i krytycznym wpływie wymagają priorytetowego potraktowania w DRP. Dla firm we Wrocławiu — ze względu na historyczne doświadczenia z powodziami — plan powinien uwzględniać scenariusz fizycznego zniszczenia serwerowni.

Krok 3 — Definiowanie RPO i RTO

RPO i RTO to dwa najważniejsze parametry każdego DRP. Determinują one, jakie technologie i procedury backupu są potrzebne.

RPO — Recovery Point Objective

RPO określa, ile danych firma może sobie pozwolić na utratę. RPO = 4 godziny oznacza, że backup musi być wykonywany co najmniej co 4 godziny. Przykłady:

• RPO = 0 (zero data loss) — replikacja synchroniczna, bazy transakcyjne, systemy płatności
• RPO = 1 godzina — serwer ERP, baza CRM, poczta e-mail
• RPO = 4 godziny — dyski sieciowe, dokumenty, systemy wewnętrzne
• RPO = 24 godziny — archiwum, intranet, środowiska testowe

RTO — Recovery Time Objective

RTO określa, jak szybko system musi zostać przywrócony do działania. RTO = 2 godziny oznacza, że od momentu zgłoszenia awarii do pełnej dostępności systemu nie może minąć więcej niż 2 godziny. Przykłady:

• RTO = 15 minut — systemy krytyczne z automatycznym failoverem (klaster HA)
• RTO = 1-2 godziny — serwer ERP, poczta, Active Directory
• RTO = 4-8 godzin — serwer plików, CRM, VPN
• RTO = 24-48 godzin — systemy pomocnicze, środowiska dev/test

RPO/RTO a koszty

Im niższe RPO i RTO, tym wyższe koszty infrastruktury. RPO = 0 wymaga replikacji synchronicznej (drogie łącza, drugi ośrodek). RPO = 4h realizuje zwykły backup na NAS. Kluczem jest dopasowanie parametrów do realnej wartości biznesowej systemów — nie każdy system potrzebuje RPO = 0.

Krok 4 — Opracowanie procedur odtwarzania

Procedury odtwarzania to serce DRP. Muszą być na tyle szczegółowe, aby technik, który nigdy nie pracował z danym systemem, mógł go odtworzyć, korzystając wyłącznie z dokumentacji.

Struktura procedury (runbook)

Każda procedura powinna zawierać:

• Warunki wstępne — co jest potrzebne: dostęp do backupu, hasła, licencje, sprzęt zastępczy
• Kroki odtwarzania — numerowane, jednoznaczne instrukcje z konkretnymi komendami i ścieżkami
• Weryfikacja — jak sprawdzić, że system działa poprawnie po odtworzeniu
• Czas odtwarzania — szacowany czas realizacji procedury
• Osoba odpowiedzialna — kto wykonuje, kto nadzoruje, kto zatwierdza

Przykładowe scenariusze

• Scenariusz 1: Awaria serwera fizycznego — odtworzenie VM z backupu na zapasowy host, weryfikacja AD, DNS, usług
• Scenariusz 2: Atak ransomware — izolacja sieci, identyfikacja wektora, odtworzenie z kopii offline, zmiana haseł, analiza forensic
• Scenariusz 3: Uszkodzenie bazy danych — odtworzenie z backupu + transaction logs, weryfikacja integralności, test aplikacji
• Scenariusz 4: Awaria serwerowni — failover do drugiej lokalizacji lub chmury, przekierowanie DNS, powiadomienie użytkowników

Gdzie przechowywać dokumentację?

DRP musi być dostępny nawet gdy cała infrastruktura IT jest niedostępna. Przechowuj kopie:

• W chmurze (np. OneDrive, Google Drive) — dostępne z dowolnego urządzenia
• Na zaszyfrowanym pendrive'ie — u osoby odpowiedzialnej za IT
• W formie wydruku — w sejfie lub u zarządu
• U partnera IT — np. u Matysiak.net.pl, który prowadzi kopię dokumentacji klientów we Wrocławiu

Krok 5 — Plan komunikacji kryzysowej

Awaria IT to nie tylko problem techniczny — to sytuacja kryzysowa, która wymaga sprawnej komunikacji. Chaos informacyjny potęguje straty.

Macierz eskalacji

• Poziom 1 (awaria pojedynczego systemu) — administrator IT → kierownik IT → użytkownicy dotknięci awarią
• Poziom 2 (awaria krytyczna, wiele systemów) — kierownik IT → zarząd → wszyscy pracownicy → kluczowi klienci
• Poziom 3 (katastrofa, utrata serwerowni) — zarząd → partner IT → ubezpieczyciel → CERT → media (jeśli dotyczy danych klientów)

Lista kontaktów kryzysowych

Przygotuj i regularnie aktualizuj listę zawierającą:

• Dane kontaktowe zespołu IT (telefon, e-mail alternatywny, komunikator)
• Dane partnera outsourcingowego IT (numer alarmowy 24/7)
• Kontakt do dostawców: hosting, chmura, ISP, serwis sprzętowy
• Kontakt do zarządu i kluczowych kierowników
• Dane ubezpieczyciela (polisa cyber)
• CERT Polska (cert.pl) — w przypadku incydentu bezpieczeństwa

Szablony komunikatów

Przygotuj gotowe szablony wiadomości na typowe scenariusze:

• Powiadomienie pracowników o awarii i przewidywanym czasie naprawy
• Informacja dla klientów o tymczasowej niedostępności usług
• Raport poincydentowy dla zarządu
• Zgłoszenie do UODO (w przypadku naruszenia danych osobowych — masz 72 godziny)

Krok 6 — Testowanie i aktualizacja

DRP, którego nigdy nie przetestowano, to tylko dokument. Plan, który wygląda dobrze na papierze, może zawieść w praktyce z powodów, których nie przewidziano.

Rodzaje testów

• Ćwiczenie tabletop (co kwartał) — zespół IT przechodzi przez scenariusz awarii na papierze, omawiając każdy krok. Tanio, szybko, ujawnia luki logiczne
• Test komponentowy (co miesiąc) — odtworzenie pojedynczego serwera/bazy z backupu na środowisku testowym. Weryfikacja, że backup działa
• Test pełny (raz w roku) — symulacja katastrofy: odtworzenie całego środowiska z backupów na alternatywnej infrastrukturze. Mierzenie rzeczywistego RTO
• Test niezapowiedziany (opcjonalnie) — losowy test bez uprzedzenia zespołu. Najlepiej sprawdza gotowość, ale wymaga dojrzałej organizacji

Co sprawdzić podczas testu?

• Czy backupy są kompletne i odtwarzalne?
• Czy procedury są zrozumiałe i aktualne?
• Czy hasła i dostępy w dokumentacji są prawidłowe?
• Czy rzeczywisty RTO mieści się w zdefiniowanym celu?
• Czy lista kontaktów jest aktualna?
• Czy zespół wie, co robić bez czytania dokumentacji?

Kiedy aktualizować DRP?

• Po każdej zmianie w infrastrukturze IT (nowy serwer, migracja, zmiana dostawcy)
• Po każdym incydencie bezpieczeństwa
• Po każdym teście DRP (wnioski → aktualizacja)
• Minimum raz w roku — nawet jeśli nic się nie zmieniło
• Po zmianach organizacyjnych (nowe osoby w IT, zmiana dostawcy)