Disaster Recovery Plan (DRP)

Disaster Recovery Plan (DRP) to udokumentowany plan działań podejmowanych w celu przywrócenia systemu po poważnej awarii.

Zakres i cel planu Disaster Recovery

Disaster Recovery Plan (DRP) jest udokumentowanym opisem działań, które mają doprowadzić do odtworzenia systemów informatycznych po poważnej awarii. Taka awaria może wynikać z uszkodzenia nośnika danych, błędnej aktualizacji, awarii zasilania, pożaru, zalania, kradzieży sprzętu albo incydentu powodującego niedostępność plików. Plan nie ogranicza się do samego wykonania kopii zapasowej. Określa również kolejność uruchamiania usług, osoby odpowiedzialne za decyzje, wymagane zasoby oraz sposób potwierdzenia, że odtworzone dane są poprawne.

DRP powinien rozróżniać systemy krytyczne od tych, których czasowa niedostępność nie zatrzymuje pracy. W praktyce opisuje się między innymi serwery, stacje robocze, aplikacje, bazy danych, urządzenia sieciowe, mechanizmy uwierzytelniania i dostęp do plików. Dla każdego elementu ustala się zależności. Przykładowo aplikacja może wymagać konkretnej bazy danych, serwera DNS, katalogu z plikami konfiguracyjnymi oraz dostępu sieciowego. Pominięcie jednej z tych zależności może sprawić, że formalnie odtworzony komputer lub serwer nadal nie będzie zdolny do pracy.

RTO, RPO i priorytety odtwarzania

Jednym z podstawowych elementów DRP są parametry RTO i RPO. Recovery Time Objective (RTO) oznacza maksymalny akceptowalny czas przywracania określonej usługi. Recovery Point Objective (RPO) określa, jak stara może być najnowsza dostępna kopia danych, aby utrata informacji była możliwa do zaakceptowania. Jeżeli RPO wynosi cztery godziny, plan powinien zapewnić możliwość odtworzenia danych najwyżej do stanu sprzed czterech godzin. Jeżeli wymagany RTO wynosi dwie godziny, sama obecność kopii zapasowej nie wystarczy, gdy jej odczyt, przygotowanie sprzętu i konfiguracja zajmują dłużej.

Wartości RTO i RPO powinny być przypisane do konkretnych usług, a nie do całej infrastruktury jednym ogólnym założeniem. Poczta elektroniczna, system obsługi zamówień, współdzielone pliki i archiwum mogą mieć różne wymagania. Na tej podstawie ustala się kolejność działań: najpierw odtwarzane są elementy niezbędne do uruchomienia pozostałych, następnie usługi o najwyższym priorytecie, a na końcu systemy pomocnicze. Takie uporządkowanie ogranicza ryzyko chaotycznego przywracania przypadkowych komponentów.

Kopie zapasowe, sprzęt zastępczy i procedura odtworzenia

Skuteczny plan musi wskazywać, gdzie znajdują się kopie zapasowe, w jakim formacie zostały zapisane i jak można je odczytać. Należy uwzględnić kopie plikowe, obrazy całych dysków, eksporty konfiguracji oraz dane wymagające odtworzenia w określonej kolejności. Sama informacja, że kopia istnieje, nie potwierdza jej użyteczności. Procedura powinna obejmować sprawdzenie daty wykonania, integralności archiwum, dostępności kluczy lub haseł oraz zgodności kopii z wersją używanego systemu.

DRP powinien opisywać także wariant awarii fizycznego urządzenia. Trzeba określić, czy odtworzenie nastąpi na tym samym komputerze po wymianie dysku, na sprzęcie zastępczym, czy w innym środowisku technicznym. Istotne są sterowniki, tryb rozruchu UEFI lub BIOS, układ partycji, konfiguracja sieci, licencje i wymagane urządzenia peryferyjne. Procedura powinna prowadzić od zabezpieczenia uszkodzonego sprzętu, przez przygotowanie nośnika lub obrazu, aż do uruchomienia systemu i kontroli aplikacji. Każdy krok powinien być zapisany tak, aby można było wykonać go również pod presją czasu.

Testowanie, dokumentacja i aktualizacja DRP

Plan odzyskiwania wymaga regularnych testów. Test może obejmować pojedynczy plik, uruchomienie obrazu systemu, odtworzenie aplikacji albo pełną symulację niedostępności kluczowej usługi. Podczas próby należy mierzyć rzeczywisty czas wykonania działań, sprawdzać kompletność danych i zapisywać problemy napotkane przez osoby odtwarzające system. Szczególnie ważne jest potwierdzenie, że kopia nie jest uszkodzona oraz że odtworzona aplikacja może odczytać dane, zapisać nową informację i komunikować się z wymaganymi zależnościami.

Dokument DRP powinien zawierać datę ostatniej weryfikacji, właściciela procedury, listę kontaktów technicznych, opis zasobów oraz historię zmian. Aktualizacji wymagają między innymi adresy urządzeń, nazwy systemów, lokalizacje kopii, hasła awaryjne, wersje oprogramowania i kolejność uruchamiania usług. Zmiana dysku, systemu operacyjnego, sposobu wykonywania kopii lub konfiguracji sieci może unieważnić wcześniejszą procedurę. Dlatego po każdej istotnej zmianie należy ponownie sprawdzić co najmniej te fragmenty planu, których dotyczy modyfikacja. Dobrze utrzymany DRP nie jest jednorazowym dokumentem, lecz aktualizowaną instrukcją odtworzenia działania po awarii.