Awaria serwera o 14:30. Ostatnia użyteczna kopia bazy danych pochodzi z 12:00, a przywrócenie aplikacji zajmuje pięć godzin. Dla firmy obsługującej kilkadziesiąt zamówień dziennie może to oznaczać uciążliwości. Dla sklepu realizującego kilkaset transakcji na godzinę – poważne straty finansowe i konieczność ręcznego odtwarzania sprzedaży.
Dlatego częstotliwość wykonywania kopii zapasowych nie powinna wynikać z domyślnych ustawień programu ani wygody administratora. Najpierw trzeba określić, ile danych firma może utracić oraz jak długo może działać bez konkretnej usługi. Dopiero na tej podstawie ustala się RPO i RTO, wybiera technologię backupu i sprawdza, czy odtworzenie systemu rzeczywiście zmieści się w przyjętych granicach.
Co oznaczają RPO i RTO i dlaczego trzeba określić je osobno?
RPO (Recovery Point Objective) określa maksymalną akceptowalną utratę danych wyrażoną w czasie. Jeśli dla bazy zamówień przyjęto RPO wynoszące 15 minut, po awarii firma musi dysponować możliwością przywrócenia danych do punktu oddalonego od momentu awarii o nie więcej niż kwadrans.
RTO (Recovery Time Objective) oznacza maksymalny dopuszczalny czas przywrócenia działania systemu lub procesu biznesowego. RTO równe dwie godziny oznacza, że w tym czasie usługa powinna ponownie działać w uzgodnionym zakresie, a nie tylko mieć uruchomiony serwer.
Oba parametry dotyczą różnych strat. RPO ogranicza utratę zapisanych informacji, natomiast RTO ogranicza czas niedostępności usługi.
Załóżmy, że serwer obsługujący system magazynowy przestaje działać o 14:30. Ostatni poprawny, dostępny punkt odtworzenia przedstawia stan bazy z 14:00. System zostaje przywrócony o 17:15.
Wynik wygląda następująco:
- Utrata danych: potencjalnie 30 minut zmian, czyli okres od 14:00 do 14:30.
- Czas przestoju: 2 godziny i 45 minut.
- RPO wynoszące 60 minut: spełnione w tym scenariuszu.
- RTO wynoszące 2 godziny: przekroczone o 45 minut.
To istotne rozróżnienie: nawet poprawnie działający backup nie gwarantuje szybkiego powrotu do pracy.
Nie można też automatycznie utożsamiać częstotliwości backupu z osiąganym RPO. Jeżeli zadanie rozpoczyna się co godzinę, ale trwa 25 minut, kończy się błędem albo nie tworzy dostępnego punktu odtworzenia, rzeczywista luka w ochronie danych może przekroczyć godzinę. Znaczenie ma czas, do którego można skutecznie odtworzyć dane, a nie sam wpis w harmonogramie. Punkt odtworzenia może odpowiadać chwili wykonania spójnej migawki, nawet jeśli przesyłanie kopii kończy się później.
Przy ustalaniu parametrów należy zastosować analizę wpływu awarii na działalność (BIA). Właściciel procesu powinien odpowiedzieć na trzy pytania: ile kosztuje godzina przestoju, ile zmian można odtworzyć z innych źródeł i kiedy przerwa zacznie powodować nieakceptowalne konsekwencje.
Jeżeli godzina niedostępności systemu kosztuje firmę szacunkowo 3000 zł, czterogodzinny przestój oznacza 12 000 zł bezpośrednich strat operacyjnych, jeszcze przed uwzględnieniem reklamacji czy utraconych klientów. Takie wyliczenie pomaga ocenić, czy inwestycja w szybsze odtwarzanie jest ekonomicznie uzasadniona.
RPO równe zero wymaga szczególnej ostrożności. Zwykły okresowy backup nie zapewni braku utraty danych. Potrzebne mogą być mechanizmy synchronicznej replikacji, które zwiększają koszty i mogą podnosić opóźnienia zapisu. Co więcej, replikacja może przenieść również przypadkowe usunięcie danych lub skutki ataku ransomware. Nie zastępuje więc niezależnych kopii historycznych.
Jak dobrać RPO i RTO do sklepu internetowego, księgowości i pozostałych usług?
Jedno RPO i jedno RTO dla całego serwera to częsty błąd. Na tej samej maszynie mogą działać aplikacje o zupełnie innym znaczeniu biznesowym. Baza transakcyjna wymaga innej ochrony niż archiwum dokumentów, nawet jeśli korzystają ze wspólnego systemu operacyjnego.
Przykładowe wartości wyjściowe dla średniej firmy przedstawiają się następująco:
| Usługa | Przykładowe RPO | Przykładowe RTO |
|---|---|---|
| Sklep internetowy – zamówienia | 15 minut | 1 godzina |
| System ERP i magazyn | 30 minut | 2 godziny |
| Serwer plików biurowych | 4 godziny | 8 godzin |
| System księgowy | 1 godzina | 4 godziny |
| Archiwum dokumentów | 24 godziny | 24–48 godzin |
Są to przykładowe cele projektowe, a nie obowiązujące normy ani gwarancje techniczne. Ostateczne wartości zależą od liczby operacji, godzin pracy, możliwości odtworzenia danych oraz wymagań umownych i prawnych.
W sklepie internetowym przyjmującym 40 zamówień na godzinę utrata 15 minut danych oznacza potencjalnie 10 zamówień wymagających odzyskania lub uzgodnienia. Jeżeli platforma zapisuje także płatności i stany magazynowe, problem może dotyczyć zgodności trzech różnych rejestrów.
W takim przypadku sens mają częste kopie spójne aplikacyjnie, mechanizmy odtwarzania bazy do określonego momentu (PITR) oraz archiwizacja dzienników transakcyjnych. Przykładowo PostgreSQL umożliwia odtwarzanie z kopii bazowej i poprawnie zarchiwizowanych plików WAL. Samo uruchomienie zadania backupu co 15 minut nie daje jednak pewności spełnienia RPO – trzeba kontrolować ciągłość archiwizacji i dostępność punktów odtworzenia.
Dla księgowości sytuacja wygląda inaczej. Przy pracy od 8:00 do 16:00 można przyjąć RTO wynoszące cztery godziny, ale podczas zamykania miesiąca albo przygotowywania deklaracji podatkowych przestój może być znacznie bardziej kosztowny. Parametry powinny więc uwzględniać okresy krytyczne dla działalności, a nie wyłącznie przeciętny dzień pracy.
Przy serwerze plików, na którym pracuje dziesięć osób, kopie wykonywane co cztery godziny mogą wystarczyć, jeśli dokumenty da się częściowo odzyskać z poczty lub lokalnych wersji. Nie będzie to rozsądny wybór dla zespołu projektowego, który jednocześnie aktualizuje wspólne pliki i nie ma dodatkowej historii zmian.
Znaczenie ma również infrastruktura. Przy wolumenie danych wynoszącym 2 TB i efektywnej prędkości przywracania 100 MB/s sam transfer zajmie około 5 godzin i 33 minut, przy założeniu 1 TB = 10¹² bajtów. Do tego dochodzi przygotowanie środowiska, uruchomienie aplikacji i kontrola poprawności danych. RTO wynoszące godzinę będzie w takim układzie nierealne, jeśli system trzeba odbudowywać od zera.
Krótsze RTO może wymagać gotowej maszyny zapasowej, replikacji lub infrastruktury umożliwiającej szybkie uruchomienie odzyskanej maszyny wirtualnej. Takie rozwiązania mają sens przy wysokich kosztach przestoju. Dla archiwum używanego kilka razy w miesiącu utrzymywanie dodatkowego środowiska produkcyjnego będzie zwykle nieproporcjonalnym wydatkiem.
Priorytet jest prosty: najpierw chronić dane i procesy, których utrata natychmiast zatrzymuje sprzedaż, produkcję lub realizację zobowiązań. Dopiero później skracać czas odtwarzania usług pomocniczych.
Jak testować odtwarzanie i dokumentować procedurę awaryjną?
Komunikat „backup zakończony pomyślnie” potwierdza wykonanie określonego zadania, ale nie dowodzi, że firma potrafi odtworzyć działającą usługę. Kopia może być niekompletna, niedostępna z powodu błędnych uprawnień albo bezużyteczna bez klucza szyfrującego.
Test odtwarzania powinien obejmować rzeczywisty scenariusz awarii, a nie tylko sprawdzenie, czy da się pobrać plik z repozytorium.
Przykład: przedsiębiorstwo deklaruje RTO wynoszące dwie godziny dla systemu ERP. W trakcie ćwiczenia administrator potrzebuje 20 minut na identyfikację problemu, 25 minut na uruchomienie serwera zastępczego, 55 minut na przywrócenie bazy oraz 30 minut na skonfigurowanie usług i sprawdzenie działania aplikacji.
Łącznie daje to 130 minut, czyli przekroczenie RTO o 10 minut. Test ujawnia problem, którego nie widać w raportach programu backupowego.
Co istotne, czas odtwarzania obejmuje również zależności: sieć, DNS, Active Directory, certyfikaty, połączenia z bazą danych, systemy uwierzytelniania i integracje z innymi aplikacjami. Jeśli ERP uruchomi się po 80 minutach, ale użytkownicy nie mogą wystawić dokumentu sprzedaży przez niedostępną usługę autoryzacji, przywracanie procesu nadal trwa.
Praktyczny test powinien przebiegać w następującej kolejności:
- Wybór punktu odtworzenia – sprawdzenie, z jakiej godziny rzeczywiście dostępne są kompletne i spójne dane.
- Przygotowanie środowiska izolowanego – odtworzenie serwera bez nadpisywania produkcji i bez ryzyka wysyłania rzeczywistych zamówień czy wiadomości.
- Przywrócenie danych i konfiguracji – z uwzględnieniem zależności aplikacyjnych, kont usługowych oraz kluczy.
- Weryfikacja biznesowa – zalogowanie użytkownika, odczyt danych oraz wykonanie reprezentatywnej operacji, np. utworzenia dokumentu testowego.
- Pomiar i raport – zapis czasu każdej czynności, faktycznego punktu odtworzenia, wykrytych błędów i działań naprawczych.
Dla usług krytycznych rozsądnym punktem wyjścia jest test kwartalny, a dla mniej istotnych – co najmniej coroczny. Dodatkowy test należy wykonać po istotnej zmianie infrastruktury, migracji bazy lub wymianie narzędzia backupowego. Są to zalecenia organizacyjne, które trzeba dopasować do ryzyka, a nie sztywne wymagania dla każdej firmy.
W dokumentacji procedury muszą znaleźć się lokalizacja kopii, kolejność odtwarzania usług, osoby odpowiedzialne, sposób uzyskania dostępu do kluczy i dane kontaktowe dostawców. Instrukcja powinna być dostępna również wtedy, gdy główny serwer plików lub system logowania nie działa.
Osobny problem stanowi ochrona kopii przed ransomware. Reguła 3-2-1 zakłada trzy egzemplarze danych, dwa rodzaje nośników i jedną kopię poza podstawową lokalizacją. W środowiskach narażonych na ataki warto dodatkowo stosować kopie niezmienialne lub odłączone od infrastruktury produkcyjnej. Sama geograficzna separacja nie wystarczy, jeśli administrator zaatakowanego systemu może usunąć wszystkie backupy.
Nie trzeba przy tym kupować drogiej platformy Disaster Recovery dla każdej aplikacji. Jeżeli test wykazuje, że lokalna kopia pozwala odzyskać usługę w wymaganym czasie, dodatkowa infrastruktura może być zbędna. Jeśli jednak odtwarzanie regularnie przekracza RTO, należy najpierw ustalić wąskie gardło: transfer, wydajność dysków, ręczną konfigurację czy brak środowiska zastępczego.
FAQ – najczęstsze pytania o RPO, RTO i kopie zapasowe
Czy backup wykonywany co godzinę gwarantuje RPO równe godzinie?
Nie. Decyduje wiek najnowszego dostępnego i poprawnego punktu odtworzenia. Opóźnienia, nieudane zadania i brak spójności danych mogą spowodować przekroczenie RPO.
Czy RTO obejmuje czas sprawdzania działania aplikacji?
Tak. Obejmuje cały czas niezbędny do przywrócenia usługi do uzgodnionego poziomu działania, w tym jej zależności oraz weryfikację poprawności.
Czy replikacja serwera zastępuje backup?
Nie. Replikacja ogranicza przestój lub utratę najnowszych zapisów, ale może przenosić błędne zmiany, usunięcia i zaszyfrowane pliki. Potrzebne są niezależne punkty odtworzenia.
Czy każda firma potrzebuje RPO wynoszącego 15 minut?
Nie. Dla rzadko aktualizowanego archiwum wystarczy czasem RPO równe 24 godziny. Dla intensywnie wykorzystywanej bazy transakcyjnej nawet 15 minut może oznaczać zbyt dużą utratę danych.
Od czego zacząć ustalanie parametrów?
Od bazy obsługującej najważniejszy proces biznesowy. Należy ustalić koszt przestoju i utraty danych, sprawdzić godzinę najnowszego użytecznego punktu odtworzenia oraz wykonać próbę przywrócenia całej usługi. Jeśli zmierzony czas lub utrata danych przekraczają zaakceptowane limity, pierwszą zmianą powinna być poprawa mechanizmu, który powoduje przekroczenie RPO albo RTO – nie automatyczne zwiększanie liczby kopii.
