Utracone zmiany i przerwa w pracy to dwa różne wyniki
- 10:00Ostatni odzyskany stanZ tej kopii przywrócono dane. Zmiany zapisane później nie są w tym scenariuszu odzyskane.
- 12:00Początek awariiUsługa przestaje obsługiwać uzgodniony proces. Rozpoczyna się pomiar przerwy.
- 15:00Odbiór przez użytkownikaAplikacja działa, dane sprawdzono, a właściciel procesu potwierdza powrót do pracy.
2 godziny utraconych zmianOd 10:00 do 12:00. Porównaj z uzgodnionym RPO.
3 godziny przerwyOd 12:00 do 15:00. Porównaj z uzgodnionym RTO.
Zacznij od czynności, którą firma musi wykonać
Rozmowę rozpocznij od procesów: obsługi zamówień, rozliczeń, pracy projektowej lub kontaktu z klientami. Dla każdego zapisz, co stanie się po godzinie, dniu i kilku dniach niedostępności. Uwzględnij terminy, pracę innych zespołów oraz możliwość czasowej obsługi ręcznej.
Właściciel procesu powinien wskazać minimalny zakres potrzebny do wznowienia pracy. Odczyt istniejących zleceń może wystarczyć na początek, podczas gdy przyjmowanie płatności wymaga pełnego działania integracji. To rozróżnienie pozwala ustalić realną kolejność odtwarzania, zamiast przyznawać każdemu serwerowi najwyższy priorytet.
Oddziel utratę zmian od czasu przerwy
RPO to cel określający maksymalną tolerowaną utratę danych wyrażoną czasem. RTO opisuje docelowy czas przywrócenia usługi po przerwie. Krótkie RPO nie zapewnia krótkiego RTO: częsta kopia może odtwarzać się długo, a szybko uruchomiony serwer może zawierać stare dane.
Przykład poglądowy: dla zamówień firma uzgadnia RPO jednej godziny i RTO czterech godzin. To wymagania do sprawdzenia, nie obietnica konkretnego narzędzia. Ustal, od jakiego zdarzenia liczysz przerwę i jaka czynność użytkownika potwierdzi koniec odtwarzania.
Rozpisz zależności i dostęp awaryjny
Dla każdej usługi wypisz aplikację, bazę, magazyn plików, logowanie, sieć, DNS oraz potrzebne certyfikaty. Zaznacz, które elementy muszą wrócić wcześniej. Sam serwer aplikacji może być gotowy, ale bez systemu tożsamości pracownicy nadal nie rozpoczną pracy.
Uwzględnij dostęp do kopii, kluczy, instrukcji i kont usługodawców. Plan przechowywany wyłącznie na niedostępnym serwerze nie pomoże w jego odbudowie. Przygotuj chronioną kopię instrukcji poza głównym środowiskiem oraz zastępstwo dla osoby, która zwykle administruje systemem. Kontakty awaryjne sprawdzaj przed ćwiczeniem.
Policz czas całego odtwarzania
Oszacuj wykrycie awarii, decyzję o odtwarzaniu, przygotowanie zasobów, transfer, uruchomienie zależności i odbiór biznesowy. Nie zastępuj tego czasu prędkością kopiowania pojedynczego pliku. Duża liczba małych obiektów, odbudowa indeksów lub ręczne zatwierdzenie dostępu mogą wydłużyć całą operację.
Porównaj wymaganie z wynikiem próby. Gdy cel jest nieosiągalny, przedstaw konkretne opcje: szybszy dostęp do kopii, przygotowany serwer zastępczy, prostsza procedura albo uzgodniony tryb pracy ograniczonej. Obniżenie celu wymaga decyzji właściciela procesu, a nie cichej zmiany dokumentacji technicznej.
Napisz plan użyteczny podczas awarii
Na pierwszej stronie umieść warunki uruchomienia planu, osoby decyzyjne, kolejność usług i kanał komunikacji. Każdy krok powinien mieć wykonawcę, warunek rozpoczęcia oraz widoczny wynik. Rozdziel zwykłą awarię sprzętu od podejrzenia włamania: w drugim przypadku potrzebne są również izolacja, analiza i wybór zaufanej kopii.
Opisz obsługę zmian powstałych podczas pracy zastępczej. Ręcznie zapisane zamówienia trzeba później uzgodnić z systemem, aby nie powstały duplikaty. Zdefiniuj też osobę, która zatwierdza powrót użytkowników i informuje ich o ewentualnej utracie danych.
Przećwicz decyzje i potwierdź założenia
Przeprowadź krótkie ćwiczenie przy stole: główny serwer nie działa, administrator jest niedostępny, a kopia znajduje się poza biurem. Sprawdź, czy zastępca potrafi odnaleźć instrukcję i ustalić następny krok. Następnie wykonaj techniczną próbę najważniejszej usługi w wydzielonym środowisku.
Warunkiem odbioru jest potwierdzone osiągnięcie celów albo jawnie zaakceptowana lista odstępstw. Zapisz rzeczywistą utratę zmian i czas wznowienia procesu. Aktualizuj plan po nowych integracjach, zmianie lokalizacji danych i zmianach odpowiedzialności. RPO oraz RTO bez dowodów pozostają założeniami.
Źródła: NIST SP 800-34 Rev. 1 — Contingency Planning Guide · NCSC New Zealand — Implement and test backups