Disaster Recovery i plan odtworzenia

Czym Disaster Recovery różni się od kopii zapasowej

Kopia zapasowa jest warunkiem, nie odpowiedzią. Odpowiada na pytanie, czy dane istnieją poza uszkodzonym systemem. Disaster Recovery odpowiada na pytanie, po ilu godzinach ludzie wracają do pracy, kto podejmuje decyzje w trakcie i w jakim porządku wstają systemy.

Różnica ujawnia się przy pierwszej poważnej awarii. Firma z kompletnymi kopiami i bez planu spędza pierwsze godziny na ustalaniu, kto ma hasło do konsoli wirtualizatora i który system jest ważniejszy. Prowadzenie samych kopii opisuje backup danych firmy, ta strona dotyczy tego, co dzieje się po awarii.

Od czego zaczynamy: analiza wpływu na biznes

Nie od technologii, tylko od pytania, co się dzieje z firmą przy każdej kolejnej godzinie przestoju. Przechodzimy proces po procesie: sprzedaż, produkcja, magazyn, obsługa klienta, kadry, i przy każdym ustalamy, po jakim czasie brak systemu przekłada się na utracone pieniądze, kary umowne albo zatrzymaną linię.

Wynik jest zwykle zaskakujący dla obu stron. Systemy uznawane w firmie za najważniejsze potrafią wytrzymać dobę, a ten jeden, o którym nikt nie mówi na zarządzie, zatrzymuje wydania z magazynu po dwóch godzinach. Dopiero ta lista pozwala wydać pieniądze tam, gdzie faktycznie skracają przestój.

Jakie liczby ustalamy dla każdego systemu

Czas powrotu ustala się osobno dla każdego systemu krytycznego, bo utrzymywanie całego środowiska w najwyższym reżimie kosztuje wielokrotnie więcej niż utrzymanie w nim dwóch systemów, które faktycznie tego wymagają.

Wymagany czas powrotu	Co musi być przygotowane	Co to oznacza w praktyce
24 do 48 godzin	kopia poza siedzibą i sprzęt zamawiany po awarii	najtańszy wariant, akceptowalny dla systemów pomocniczych
4 do 8 godzin	kopia lokalna i host zastępczy czekający na miejscu	odtwarzanie zaczyna się od razu, bez czekania na dostawę
do 1 godziny	replika maszyny w drugiej lokalizacji	uruchamiamy kopię zamiast odtwarzać dane
minuty	replikacja ciągła i przełączanie między lokalizacjami	rozwiązanie dla systemów, które zatrzymują przychód

Do tego druga liczba, czyli akceptowalna utrata danych. Ona nie wynika z planu, tylko z harmonogramu kopii, i to jedyne miejsce, w którym plan sięga do usługi backupu.

Cztery scenariusze, które opisujemy zawsze

Atak ransomware. Izolacja zajętych systemów, ustalenie momentu wejścia atakującego, odtworzenie z kopii sprzed infekcji, weryfikacja danych przed powrotem na produkcję i dopiero potem przywracanie dostępu użytkownikom.

Awaria sprzętu. Uruchomienie maszyny zastępczej albo przejęcie roli przez drugi host, z listą części i kontaktem serwisowym pod ręką.

Utrata budynku. Pożar, zalanie, brak zasilania albo brak dostępu do lokalizacji. Odtwarzanie z zasobów spoza budynku, z tymczasowym miejscem pracy dla zespołu.

Błąd człowieka. Skasowany katalog, nadpisana baza, wysłana masowa zmiana. Zwykle powrót ze snapshotu bez uruchamiania całego planu, ale z tym samym obiegiem zgłoszenia i potwierdzenia.

Każdy scenariusz ma spisane role: kto ogłasza incydent, kto decyduje o odtwarzaniu, kto informuje pracowników i kto rozmawia z klientami. Sam obieg techniczny ataku, od wykrycia po odcięcie, opisuje ochrona przed ransomware.

Jak wygląda ćwiczenie planu

Ćwiczenie ma dwie formy i obie są potrzebne. Pierwsza to próba przy stole: prowadzimy zespół przez scenariusz godzina po godzinie, bez dotykania produkcji, i notujemy każde miejsce, w którym ktoś nie wie, co robić. Zwykle wychodzi tam brak kontaktu do dostawcy łącza, nieaktualna lista osób albo hasło zapisane u jednej osoby, która akurat jest na urlopie.

Druga forma to próba techniczna: uruchamiamy systemy w środowisku zapasowym, mierzymy czas i sprawdzamy, czy aplikacje faktycznie startują, a nie tylko czy maszyny wstają. Wynik obu prób trafia do raportu razem z listą poprawek i terminem ich wdrożenia. Plan, który nigdy nie był ćwiczony, jest dokumentem, a nie zabezpieczeniem.

Co mówi ISO 22301 i NIS 2

ISO 22301 to norma zarządzania ciągłością działania. Wymaga analizy wpływu na biznes, ustalonych czasów powrotu, udokumentowanych procedur i regularnych testów, czyli dokładnie tego, z czego składa się plan. NIS 2 nakłada obowiązek ciągłości działania i zarządzania kryzysowego na podmioty objęte dyrektywą, razem z obowiązkiem zgłaszania poważnych incydentów w określonych terminach.

Plan piszemy tak, żeby dało się go pokazać audytorowi bez tłumaczenia, i żeby raporty z ćwiczeń były dowodem, a nie notatką w skrzynce. Wdrożenie samego systemu zarządzania bezpieczeństwem opisuje ISO 27001.

Czego plan nie załatwia

Nie skróci odtwarzania, jeśli kopie leżą wyłącznie w chmurze, a łącze ma dziesięć megabitów. Nie zastąpi decyzji o pieniądzach: czas powrotu poniżej godziny wymaga drugiego środowiska i to jest wydatek, nie zapis w dokumencie. Nie zadziała też sam z siebie, gdy przez rok nikt go nie otworzył, a firma w tym czasie zmieniła serwerownię.

Dlatego plan ma właściciela po Waszej stronie, datę przeglądu i ćwiczenie w kalendarzu. Zakres i cenę ustalamy przez kontakt, a rząd wielkości kosztu bieżącej opieki nad infrastrukturą policzycie w kalkulatorze.

Treść sprawdzona i zaktualizowana: 31 lipca 2026