Scenariusze disaster recovery

Scenariusze disaster recovery obejmują różne typy awarii, od utraty dysku po całkowitą niedostępność serwerowni.

Zakres scenariusza disaster recovery

Scenariusz disaster recovery opisuje sposób odtworzenia działania systemów po awarii oraz kolejność czynności wykonywanych przez osoby odpowiedzialne za infrastrukturę. Nie ogranicza się do samego wykonania kopii zapasowej. Powinien wskazywać, jakie usługi są krytyczne, od czego zależą, gdzie znajdują się dane odtworzeniowe, kto podejmuje decyzję o przełączeniu oraz jak potwierdzić poprawność działania po przywróceniu. Zakres może obejmować uszkodzenie pojedynczego dysku, awarię macierzy, błąd systemu operacyjnego, usunięcie danych, zaszyfrowanie plików przez ransomware, awarię zasilania, niedostępność łącza albo całkowitą utratę lokalizacji.

Każdy scenariusz powinien mieć jasno określone warunki rozpoczęcia i zakończenia. Warunkiem rozpoczęcia może być brak możliwości uruchomienia systemu, przekroczenie ustalonego czasu niedostępności albo potwierdzenie, że naprawa podstawowego środowiska nie będzie możliwa w wymaganym czasie. Zakończenie nie powinno oznaczać wyłącznie uruchomienia serwera. Należy również sprawdzić dostęp do danych, działanie usług zależnych, spójność zapisów oraz możliwość wykonywania nowych kopii zapasowych.

RPO, RTO i priorytety odtwarzania

Do opisania wymagań wykorzystuje się dwa podstawowe parametry. RPO, czyli Recovery Point Objective, określa maksymalną akceptowalną utratę danych wyrażoną jako czas. Jeżeli dla systemu przyjęto RPO wynoszące cztery godziny, kopia lub replika powinna pozwolić odtworzyć stan nie starszy niż cztery godziny przed awarią. RTO, czyli Recovery Time Objective, określa maksymalny czas przywrócenia usługi do działania. RPO dotyczy więc punktu odzysku danych, a RTO czasu niedostępności.

W praktyce nie wszystkie systemy odtwarza się jednocześnie. Najpierw przywraca się elementy wymagane przez inne usługi, następnie systemy o najwyższym priorytecie, a na końcu komponenty pomocnicze. Kolejność powinna uwzględniać zależności między serwerami, usługami katalogowymi, bazami danych, magazynami plików i aplikacjami. Należy także opisać tryb pracy tymczasowej, na przykład dostęp tylko do odczytu albo ręczne przyjmowanie danych do czasu zakończenia pełnego odtwarzania. Bez takiej hierarchii zespół może uruchomić pojedynczą aplikację, która nadal nie działa, ponieważ brakuje jej bazy danych lub usługi uwierzytelniania.

Kopie zapasowe i warianty awarii

Ochrona przed utratą danych wymaga dopasowania kopii zapasowych do rodzaju zagrożenia. Kopia pełna zawiera cały chroniony zestaw danych, natomiast kopie przyrostowe zapisują zmiany od wykonania poprzedniej kopii, a różnicowe zmiany od ostatniej kopii pełnej. Przy odtwarzaniu kopii przyrostowych potrzebny jest właściwy łańcuch kopii, dlatego jego integralność należy okresowo kontrolować. Sama obecność plików kopii na dysku nie potwierdza, że da się z nich poprawnie odtworzyć system.

W scenariuszu obejmującym uszkodzenie dysku można odtworzyć dane na nowym nośniku, ale awaria macierzy, kontrolera albo całego hosta może wymagać przygotowania alternatywnego środowiska. Zasada 3-2-1 oznacza utrzymywanie co najmniej trzech kopii danych, na dwóch różnych rodzajach nośników, z jedną kopią przechowywaną poza podstawową lokalizacją. W przypadku złośliwego szyfrowania przydatna jest kopia odłączona od bieżącej infrastruktury albo zabezpieczona przed modyfikacją. RAID zwiększa dostępność przy awarii wybranych dysków, lecz nie zastępuje kopii zapasowej, ponieważ błędne usunięcie plików lub ich zaszyfrowanie może zostać zapisane na wszystkich dostępnych dyskach.

Testowanie i dokumentowanie odtworzenia

Scenariusz disaster recovery powinien być testowany w warunkach możliwie zbliżonych do rzeczywistej awarii. Test może obejmować odtworzenie pojedynczego pliku, uruchomienie systemu z kopii, odtworzenie całej usługi albo przełączenie na zapasową lokalizację. Wynik należy mierzyć względem założonych wartości RPO i RTO. Warto odnotować czas pobrania kopii, czas przygotowania nośników, błędy uprawnień, brakujące zależności oraz czynności wykonane ręcznie.

Dokumentacja powinna zawierać adresy i nazwy zasobów, wymagane konta techniczne, kolejność komend lub operacji, sposób weryfikacji danych oraz procedurę powrotu do środowiska podstawowego. Dane dostępowe nie powinny być zapisywane wprost w publicznym dokumencie; procedura może wskazywać bezpieczne miejsce ich przechowywania. Po każdym teście należy zaktualizować instrukcję, ponieważ zmiany konfiguracji, nośników, nazw usług i zależności mogą spowodować, że dawny scenariusz przestanie być wykonalny. Regularne próby odtworzeniowe ujawniają problemy, których nie widać podczas samego monitorowania kopii zapasowych.