RPO i RTO często lądują w tabeli obok słowa „backup”. To jeszcze nie jest plan odtwarzania. Najpierw trzeba powiedzieć, co ma wrócić: baza, API czy możliwość dokończenia sprawy przez użytkownika.

Dwie różne miary

RPO (Recovery Point Objective) określa maksymalną dopuszczalną utratę danych w czasie: jak daleko wstecz może sięgać ostatni poprawny odtworzony zapis. RTO (Recovery Time Objective) określa maksymalny czas od przerwania usługi do przywrócenia uzgodnionej funkcji. Doprecyzuj początek pomiaru, zakres funkcji i to, kto akceptuje wynik. RPO nie jest harmonogramem kopii; RTO nie jest czasem uruchomienia maszyny.

Przykład fikcyjny. Portal ma RPO 5 minut i RTO 30 minut. Awaria zostaje wykryta o 10:00. Ostatni poprawnie odtworzony zapis pochodzi z 09:52, a użytkownik może znów złożyć i odczytać wniosek o 10:42. Osiągnięte wartości wynoszą co najmniej 8 minut utraty zapisów i 42 minuty niedostępności. Oba cele są przekroczone, choć kopia bazy mogła wykonać się o 09:55.

Dlaczego kilka magazynów zmienia rachunek

Metadane w bazie, załączniki w obiektowym magazynie i komunikaty w kolejce nie tworzą automatycznie jednej transakcji odtworzeniowej. Możesz odzyskać wiersz bez pliku albo ponowić już obsłużony komunikat. Ustal identyfikator biznesowy do uzgadniania danych, procedurę wykrywania braków oraz sposób obsługi duplikatów. Gdy spójnego punktu nie da się zapewnić technicznie, opisz proces kompensacji i zatwierdzania strat.

Próba, która ma sens

  1. Wybierz krytyczną ścieżkę użytkownika i wszystkie potrzebne do niej zależności. Rozróżnij cele dla pełnej funkcji i ograniczonego trybu pracy.
  2. W odizolowanym środowisku zasymuluj niedostępność głównego regionu. Sprawdź dostęp do kopii, kluczy i procedury bez polegania na tym regionie.
  3. Odtwórz realistyczną ilość danych i usług; zmierz czas od wykrycia do poprawnego testu ścieżki, a nie do „serwer odpowiada”.
  4. Uzgodnij zapisy, pliki i komunikaty. Policz ostatni dostępny zapis, brakujące obiekty, duplikaty i pracę wymagającą ręcznego dokończenia.
  5. Porównaj wynik z celami. Zapisz właściciela i termin każdej poprawki; powtórz test po ważnej zmianie architektury.

Wybór między częstszą replikacją, kopią, aktywną redundancją i ręcznym obejściem zależy od kosztu utraty danych oraz przerwy. Każda opcja przenosi inny koszt i inne ryzyko; żadna nie zwalnia z próby. Replikacja może wiernie skopiować także błędny zapis.

Pytanie do projektu: kiedy ostatnio odtworzyliście pełną czynność użytkownika i jaki był zmierzony, a nie zadeklarowany RPO oraz RTO?