Disaster recovery to nie jest kolejny dokument do segregatora. To zestaw decyzji i procedur, które w dniu poważnej awarii decydują, czy firma wraca do pracy po kilku godzinach, czy po kilku tygodniach. W praktyce audytorskiej widzę tu ten sam wzorzec: firma ma backup, ale nikt nie wie, w jakiej kolejności odtwarzać systemy i kto za co odpowiada.

Czym plan DR różni się od backupu

Backup to kopia danych. Disaster recovery to plan przywrócenia działania firmy jako całości: serwerów, aplikacji, sieci, dostępów i ludzi. Kopia bez planu odtwarzania jest jak gaśnica bez instrukcji obsługi w czasie pożaru.

Dobry plan DR obejmuje:

  • listę procesów krytycznych i systemów, które je obsługują,
  • kolejność odtwarzania (co uruchamiamy najpierw, co może poczekać),
  • role i osoby decyzyjne wraz z danymi kontaktowymi,
  • procedury techniczne odtwarzania krok po kroku,
  • kryteria uznania sytuacji za katastrofę i uruchomienia planu.

Zacznij od analizy wpływu na biznes

Zanim policzysz cokolwiek technicznego, odpowiedz na pytanie biznesowe: które procesy muszą działać, żeby firma zarabiała i nie łamała umów. To analiza wpływu na działalność, po angielsku Business Impact Analysis.

Dla każdego procesu ustal:

  1. jak długo firma przetrwa bez niego, zanim pojawią się realne straty,
  2. jakie systemy i dane są mu potrzebne,
  3. kto jest właścicielem procesu i kogo trzeba powiadomić.

Dopiero z tej analizy wynikają parametry techniczne. Bez niej łatwo wydać duże pieniądze na odtwarzanie systemu, który spokojnie mógłby poczekać dobę.

RTO i RPO, czyli twarde liczby planu

Dwa parametry spinają cały plan DR i muszą być ustalone dla każdego systemu z osobna.

  • RTO to maksymalny akceptowalny czas przywrócenia usługi. Ile godzin firma wytrzyma bez danego systemu.
  • RPO to maksymalna akceptowalna utrata danych mierzona w czasie. Ile pracy możesz stracić, bo mieści się między kopiami.

Serwer plików może mieć RTO na poziomie ośmiu godzin, a system do fakturowania jednej godziny. Te liczby wprost przekładają się na koszt rozwiązania i częstotliwość kopii.

Zdanie o RTO cztery godziny brzmi dobrze na spotkaniu. Problem zaczyna się, gdy pytam, kto o drugiej w nocy uruchomi odtwarzanie i czy ma do tego hasła. Plan DR bez przypisanych ludzi to tylko życzenie.

Zaprojektuj scenariusze awarii

Nie ma sensu pisać planu na jedną abstrakcyjną katastrofę. Warto rozpisać kilka realistycznych scenariuszy, bo różnią się reakcją:

  • awaria pojedynczego serwera lub macierzy dyskowej,
  • atak ransomware, który szyfruje produkcję i zasoby sieciowe,
  • utrata całej lokalizacji, na przykład pożar lub zalanie serwerowni,
  • awaria dostawcy chmury lub łącza internetowego.

Dla każdego scenariusza opisz sygnał alarmowy, osobę decyzyjną i pierwsze trzy kroki. Ransomware jest tu wyjątkowo ważny, bo wymaga izolacji środowiska, zanim zaczniesz cokolwiek odtwarzać. Odtworzenie danych do zainfekowanej sieci to powtórka katastrofy.

Infrastruktura, która wspiera odtwarzanie

Plan DR wymaga zaplecza. W praktyce oznacza to najczęściej:

  • kopie w modelu 3-2-1 z jedną kopią niezmienną poza lokalizacją,
  • druga lokalizacja lub chmura, do której można przełączyć kluczowe usługi,
  • wirtualizacja, dzięki której serwer odtwarzasz jako maszynę, a nie składasz sprzęt od zera,
  • aktualna dokumentacja sieci, adresacji i zależności między systemami.

Im lepiej opisane zależności, tym mniejsze ryzyko, że po odtworzeniu bazy danych okaże się, że aplikacja nie wstaje, bo brakuje usługi katalogowej.

Test to jedyny dowód, że plan działa

Plan disaster recovery, którego nikt nie przećwiczył, jest wart tyle co niesprawdzony backup. Test odkrywa braki, których nie widać na papierze: nieaktualne hasła, brakujące licencje, złą kolejność uruchamiania.

Zalecam trzy poziomy testów:

  1. przegląd dokumentu na sucho z zespołem, kilka razy w roku,
  2. odtwarzanie wybranego systemu w środowisku testowym,
  3. pełne ćwiczenie przełączenia kluczowych usług przynajmniej raz w roku.

Po każdym teście aktualizuj plan. Środowisko IT żyje, a plan sprzed roku często opisuje firmę, która już nie istnieje.

Od czego zacząć

Jeśli zaczynasz od zera, zrób to w tej kolejności:

  1. spisz procesy krytyczne i przypisz im RTO oraz RPO,
  2. sprawdź, czy obecne kopie w ogóle pozwalają dotrzymać tych parametrów,
  3. opisz dwa lub trzy scenariusze awarii i pierwsze kroki reakcji,
  4. wyznacz osoby odpowiedzialne i zapisz dane kontaktowe,
  5. zaplanuj pierwszy test odtwarzania w kalendarzu.

Budowa dojrzałego planu wymaga połączenia wiedzy o biznesie z twardą techniką. Jeśli chcesz oprzeć się na sprawdzonym schemacie, zobacz, jak realizujemy disaster recovery oraz backup serwerów. Chętnie przejrzę z Tobą obecne kopie i pokażę, gdzie plan ma dziury, zanim zrobi to awaria.