procedury disaster recovery

Procedury Disaster Recovery – koło ratunkowe dla twojego biznesu

Procedury Disaster Recovery

Od sprawnego przywrócenia środowiska IT i innych aktywów w przypadku zaistnienia poważnej awarii zależy bezpośrednio rozmiar strat, które organizacja ponosi w wyniku utraty ciągłości działania. Procedury disaster recovery są zatem nieodzownym elementem planu zachowania ciągłości biznesowej (Business Continuity Plan).

Niestety wciąż jeszcze spotyka się organizacje, które pomimo dużych strat jakie wywołać może przerwa w działaniu procesów biznesowych traktują procedury disaster recovery jak przykry obowiązek dokumentacyjny.

Admin naprawi (albo i nie)

Bardzo często procedury disaster recovery są lekceważone przez osoby odpowiedzialne za działanie określonego procesu czy usługi. Na pytanie jak organizacja poradzi sobie w przypadku zaistnienia poważnej awarii padają odpowiedzi w stylu: „mamy backupy i informatyków, którzy je przywrócą”.

Często też sami administratorzy systemów podchodzą do tematu awarii ze stoickim spokojem, twierdząc, że są przygotowani na każdą ewentualność. „Mamy backupy, mamy zapasowy sprzęt, znamy te systemy od podszewki i szybko je skonfigurujemy w razie potrzeby”. Proszeni o podanie kolejnych działań koniecznych do przywrócenia zasobu administratorzy wymieniają najczęściej listę czynności:

  • Weźmiemy sprzęt zapasowy, mamy taki, który pozostał po wycofaniu z użycia.
  • Zainstalujemy na nim potrzebne systemy i oprogramowanie.
  • Przywrócimy dane z backupów, robimy je codziennie więc będą aktualne.
  • Zajmie nam to około 2-3 godzin a dopuszczalny przestój to 4 godziny.

Chwila próby

W krytycznej chwili okazuje się niestety, że procedury disaster recovery, które były tylko w głowie informatyków nie są wystarczająco doskonałe. Żaden bowiem plan działania nie może być dobry, jeżeli nie został nigdy sprawdzony w praktyce. Należy pamiętać, że w chwili próby wszyscy działają w stresie i pośpiechu. Nawet najprostsze czynności mogą wówczas nastręczyć problemów. Nietrudno też wtedy o pomyłkę, która spowodować może jeszcze większe szkody i wydłużyć cały proces przywracania.

Na pewno warto zatem zawczasu odpowiednio się przygotować i przetestować całą procedurę. Okazuje się wówczas, że nasz doskonały plan, który mieliśmy w głowie to bomba z opóźnionym zapłonem. W praktyce dopiero dowiadujemy się ile kwestii wymagało dodatkowego przemyślenia:

  • Czy sprzęt zapasowy spełnia wymogi oprogramowania, które w międzyczasie wielokrotnie mogło zostać aktualizowane?
  • Czy jego wydajność jest wystarczająca by utrzymać system, który rozrastał się latami?
  • Kiedy był ostatnio testowany albo przynajmniej uruchamiany?
  • Czy odtworzenie na nim systemów nie spowoduje naruszenia licencji albo konieczności ponownej aktywacji?
  • Skąd weźmiemy wersje instalacyjne oprogramowania?
  • Czy w chwili awarii będziemy mieli dostęp do Internetu?
  • Gdzie przechowujemy klucze licencyjne konieczne do instalacji/aktywacji?
  • Czy odtworzenie danych z backupu będzie możliwe jeśli awarii ulegnie serwer odpowiedzialny za ich wykonywanie?
  • Czy w przypadku awarii urządzenia, na którym przechowujemy backupy mamy dostęp do innych kopii bezpieczeństwa?
  • Czy byliśmy przygotowani na to, że cryptolockery mogły zaszyfrować nasze backupy?
  • Czy wszystkie osoby konieczne do przeprowadzenia prac będą dostępne?
  • Czy na to wszystko rzeczywiście wystarczą nam 2-3 godziny?

Jak widać nawet proste na pierwszy rzut oka czynności wymagane do przywrócenia pojedynczego serwera wiążą się z całą gamą problemów, które możemy napotkać.

O czym trzeba pamiętać?

Procedury disaster recovery muszą być przemyślane i podlegać praktycznemu sprawdzeniu. Bezwzględnie też muszą być aktualizowane. Testowanie i aktualizacja procedur DR powinno się odbywać cyklicznie, według z góry ustalonego harmonogramu. Warto też testować i aktualizować procedury odtworzeniowe po każdej większej modyfikacji systemów.

W procedurach musimy uwzględnić nie tylko dostępność określonych zasobów fizycznych i instrukcje ich przywracania, ale również dostępność personelu wymaganego do przeprowadzenia procedur. Warto zadać sobie pytanie co się stanie gdy administrator danego systemu w trakcie awarii będzie niedostępny.

Jeżeli wydaje nam się, że pomyśleliśmy już o wszystkim, to warto zadać sobie ostatnie pytanie – gdzie znajdziemy procedury disaster recovery w chwili gdy będą nam najbardziej potrzebne? Może na dysku serwera, który właśnie uległ awarii?

Wszystkie te kwestie powinniśmy zawczasu uregulować odpowiednimi zapisami w polityce bezpieczeństwa zawierającej plan ciągłości działania (BCP). Jest to nieodzowny element m.in. w Systemach Zarządzania Bezpieczeństwem Informacji.

Umieszczony na tej stronie dokument stanowi przykład prostej procedury odtworzeniowej zasobu w postaci serwera plików. Zachęcam do jego wykorzystania, udoskonalania i dalszego udostępniania.

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.