Disaster recovery w firmie — jak zbudować plan odtwarzania systemów IT

Disaster recovery to uporządkowany zbiór procedur i technologii, które pozwalają przywrócić działanie systemów po awarii macierzy dyskowej, ataku ransomware, zalaniu serwerowni lub błędzie administratora. Dobrze zaprojektowany disaster recovery nie kończy się na kopii zapasowej zapisanej na dysku zewnętrznym, lecz opiera się na dwóch mierzalnych parametrach: RTO, czyli dopuszczalnym czasie przestoju, oraz RPO, czyli akceptowalnej utracie danych liczonej w minutach lub godzinach. Dla sklepu internetowego generującego 40 000 zł obrotu dziennie każda godzina niedostępności kosztuje około 1 700 zł utraconej sprzedaży, nie licząc obsługi reklamacji i spadku zaufania klientów. Ten poradnik pokazuje, jak policzyć realne ryzyko, dobrać architekturę kopii i replikacji, odtworzyć stanowiska pracy oraz przetestować cały scenariusz, zanim wydarzy się awaria. Znajdziesz tu konkretne widełki kosztów w złotówkach, gotową tabelę priorytetów i listę kontrolną, którą można wdrożyć w firmie zatrudniającej od pięciu do dwustu osób.

Czym różni się disaster recovery od zwykłego backupu

Backup i disaster recovery to nie synonimy. Kopia zapasowa odpowiada na pytanie, czy dane przetrwały; plan odtwarzania odpowiada na pytanie, po jakim czasie firma znów fakturuje, wysyła paczki i obsługuje zgłoszenia. Dane zapisane na taśmie, ale pozbawione środowiska, w którym można je uruchomić, nie generują przychodu.

RTO określa maksymalny czas od wystąpienia awarii do przywrócenia usługi. RPO wskazuje, ile pracy wolno stracić — jeśli kopia wykonuje się raz na dobę o trzeciej w nocy, a awaria nastąpi o siedemnastej, tracisz czternaście godzin wprowadzonych zamówień, korekt i wiadomości od klientów.

Oba parametry ustala się osobno dla każdej usługi, bo koszt rośnie wykładniczo wraz z ich zaostrzaniem. RTO na poziomie czterech godzin dla serwera plików bywa tanie, natomiast piętnaście minut dla bazy transakcyjnej wymaga replikacji synchronicznej i drugiego ośrodka, co potrafi potroić roczny rachunek.

RTO i RPO — parametry, które ustalają budżet

Zanim podpiszesz umowę z dostawcą, wypisz pięć procesów krytycznych i przypisz każdemu wartość jednej godziny przestoju w złotówkach. Ta liczba, a nie moda na chmurę, decyduje, czy potrzebujesz replikacji ciągłej, czy wystarczy nocna kopia przyrostowa z retencją trzydziestu dni.

Analiza ryzyka: co naprawdę psuje się w firmach

Statystyka bywa nieintuicyjna: znacznie częściej niż pożar serwerowni zdarza się skasowanie katalogu przez pracownika, uszkodzenie kontrolera RAID, wygaśnięcie certyfikatu albo zaszyfrowanie zasobów przez ransomware z załącznika. Analizę ryzyka zaczynaj od scenariuszy prawdopodobnych, nie od tych najbardziej spektakularnych.

Skutki przestoju wychodzą daleko poza dział IT. Kilkudniowa niedostępność witryny potrafi cofnąć wyniki, jakie dało wcześniejsze pozycjonowanie strony w Google, bo roboty indeksujące trafiają na błędy 5xx, a konkurencja przejmuje pozycje organiczne. Odzyskanie widoczności zajmuje tygodnie, a budżet reklamowy musi nadrabiać stracony ruch.

W handlu elektronicznym dochodzi warstwa integracji. Zablokowane konto Google Merchant po wielogodzinnej awarii feedu produktowego oznacza wstrzymanie kampanii, a przywrócenie statusu zatwierdzonego trwa od jednego do kilku dni roboczych — nawet gdy sklep już działa poprawnie. Dlatego integracje zewnętrzne wpisuje się do planu jako osobne pozycje.

Firmy, dla których podstawą przychodu jest projektowanie stron internetowych, ponoszą dodatkowo ryzyko cudze: awaria jednego serwera zatrzymuje kilkadziesiąt witryn klientów naraz. Umowa SLA powinna rozdzielać odpowiedzialność za kopie kodu, bazy danych i plików multimedialnych, ponieważ każdy z tych zbiorów odtwarza się zupełnie inaczej.

Architektura kopii zapasowych i replikacji

Fundamentem pozostaje reguła 3-2-1, rozszerzana obecnie do 3-2-1-1-0. Trzy kopie danych, na dwóch różnych nośnikach, jedna poza siedzibą firmy, jedna niezmienialna lub offline oraz zero błędów w zweryfikowanym odtworzeniu. Ostatni element bywa pomijany i to właśnie on najczęściej mści się podczas prawdziwej awarii.

Reguła 3-2-1-1-0 w praktyce

• Trzy niezależne kopie: produkcja plus dwie repliki na osobnych zasobach.
• Dwa różne nośniki: macierz dyskowa i magazyn obiektowy lub taśma LTO.
• Jedna kopia poza budynkiem, oddalona o co najmniej kilkadziesiąt kilometrów.
• Jedna kopia niezmienialna albo odłączona fizycznie od sieci.
• Zero błędów w cyklicznym teście odtworzenia, potwierdzonym raportem.

Kopię poza siedzibą najtaniej realizuje się na zdalnym serwerze. Niedrogi OVH VPS z dyskiem 160 GB kosztuje od kilkudziesięciu złotych miesięcznie i wystarcza jako repozytorium kopii przyrostowych dla kilkunastu witryn, o ile transfer szyfrujesz, a dostęp ograniczasz kluczem SSH zamiast hasła.

Niezmienialność chroni przed ransomware, który w pierwszej kolejności szuka repozytoriów kopii i kasuje migawki. Blokada zapisu na okres od czternastu do trzydziestu dni w magazynie obiektowym kosztuje zwykle kilka groszy za gigabajt i pozostaje najtańszym ubezpieczeniem w całym planie odtwarzania.

Replikacja stanowi osobną warstwę: kopiuje stan maszyny wirtualnej co kilka minut do drugiej lokalizacji, skracając RTO do kilkunastu minut. Nie zastępuje jednak backupu, ponieważ wiernie powiela także uszkodzenia logiczne i zaszyfrowane pliki, jeśli nie zatrzymasz jej odpowiednio wcześnie.

Odtwarzanie stanowisk pracy, poczty i dostępów

Plany odtwarzania zwykle kończą się na serwerach, tymczasem firma nie pracuje bez stanowisk. Po zalaniu biura trzeba w kilkadziesiąt godzin skompletować sprzęt, przywrócić profile użytkowników, dostęp do poczty i licencje, a dopiero potem myśleć o wydajności środowiska. Lista zakupowa przygotowana wcześniej skraca ten etap o dobę.

Dla działu graficznego priorytetem jest tablet graficzny Wacom i skalibrowany monitor, dla programistów — sprawna klawiatura mechaniczna oraz szybki dysk NVMe. Kompaktowa klawiatura mechaniczna 60 procent zajmuje mniej miejsca w zapasowym biurze, a klawiatura gamingowa mechaniczna posłuży jako awaryjny zamiennik, jeśli akurat leży w magazynie.

Poczta i dokumenty w chmurze wymagają osobnego backupu, ponieważ dostawca odpowiada za infrastrukturę, nie za twoje błędy. W zestawieniach dostawców Google Workspace cena startuje od kilkudziesięciu złotych za użytkownika miesięcznie, jednak usunięta skrzynka znika bezpowrotnie po okresie retencji, dlatego zewnętrzne archiwum jest konieczne.

Osobno zabezpiecz dostęp administracyjny. Po odtworzeniu serwera WordPress logowanie do panelu bywa niemożliwe, bo zmienił się adres IP, wygasł certyfikat albo wtyczka dwuskładnikowa straciła powiązanie z aplikacją. Zapasowe konto administratora i kopia klucza odzyskiwania w sejfie haseł rozwiązują ten problem w pięć minut.

Testy, koszty i dokumentacja planu odtwarzania

Plan disaster recovery, którego nikt nie testował, pozostaje wyłącznie hipotezą. Test odtworzeniowy raz na kwartał, wykonany w izolowanej sieci, weryfikuje trzy rzeczy: czy kopia daje się w ogóle zamontować, czy aplikacja startuje po przywróceniu i czy zmierzony czas mieści się w deklarowanym RTO.

Budżet rozkłada się przewidywalnie. Licencje oprogramowania backupowego to zwykle 300–900 zł rocznie za maszynę, magazyn obiektowy 20–60 zł za terabajt miesięcznie, a drugi ośrodek z replikacją 400–2 000 zł miesięcznie. Suma rzadko przekracza dwa procent rocznych kosztów działu IT.

Dokumentacja musi być czytelna dla kogoś, kto nie budował systemu. Wersja papierowa i kopia na telefonie ratują sytuację, gdy sieć nie działa. Zapisz kolejność uruchamiania usług, dane kontaktowe dostawców, numery umów oraz osobę decydującą o ogłoszeniu awarii. Bez tej roli zespół traci pierwsze godziny na uzgodnienia.

Do zespołu kryzysowego włącz również osoby spoza IT. Specjalista odpowiedzialny za pozycjonowanie strony przygotuje komunikat i stronę zastępczą z kodem 503 zamiast 404, dzięki czemu wyszukiwarki potraktują przerwę jako tymczasową, a nie jako trwałe usunięcie zasobów. Ten szczegół realnie ogranicza straty w ruchu organicznym.

Jak często testować plan odtwarzania po awarii?

Pełny test odtworzeniowy przeprowadzaj raz na kwartał, a skrócony — przywrócenie pojedynczego pliku i jednej skrzynki pocztowej — raz w miesiącu. Kwartalny cykl wynika z tempa zmian w środowisku: w ciągu trzech miesięcy zwykle pojawia się nowa maszyna wirtualna, aktualizacja bazy danych albo zmiana wtyczek, których stara procedura nie obejmuje. Test wykonuj na odizolowanej sieci, żeby przywrócone systemy nie próbowały łączyć się z produkcją. Mierz stoperem realny czas od decyzji do uruchomienia usługi i porównuj go z deklarowanym RTO. Każdy test zamykaj krótkim raportem z listą rozbieżności i terminem ich usunięcia, inaczej te same błędy powtórzą się przy prawdziwej awarii.

Czy kopia zapasowa w chmurze wystarczy zamiast planu odtwarzania?

Sama kopia w chmurze to za mało. Dostawcy usług chmurowych działają w modelu współdzielonej odpowiedzialności: gwarantują dostępność infrastruktury, ale nie odtworzą danych skasowanych przez użytkownika ani zaszyfrowanych przez ransomware po upływie okresu retencji, który zwykle wynosi od trzydziestu do sześćdziesięciu dni. Do tego dochodzi czas pobierania: odtworzenie dwóch terabajtów przez łącze 100 Mb/s zajmuje ponad czterdzieści godzin, co samo w sobie łamie założone RTO. Rozsądny model łączy szybką kopię lokalną, z której odtwarzasz w godzinę, z kopią zdalną i niezmienialną, ratującą sytuację przy pożarze lub kradzieży sprzętu. Chmura jest jednym z filarów, nie całą konstrukcją.

Co powinien zawierać dokument planu odtwarzania systemów?

Dokument zaczyna się od listy usług krytycznych z przypisanymi wartościami RTO i RPO oraz kosztem godziny przestoju wyrażonym w złotówkach. Dalej opisz architekturę kopii: gdzie leżą, jak są szyfrowane, kto ma do nich dostęp i jak długo są przechowywane. Kolejna sekcja to procedury krok po kroku dla trzech scenariuszy — utraty pojedynczego serwera, utraty całej lokalizacji oraz incydentu ransomware — każda z kolejnością uruchamiania usług. Dołącz macierz kontaktów: administratorzy, dostawca łącza, hosting, ubezpieczyciel, numery umów i identyfikatory zgłoszeń. Na końcu umieść dziennik testów z datami i wynikami oraz wskaż osobę uprawnioną do ogłoszenia stanu awarii i przełączenia na ośrodek zapasowy.