RTO (Recovery Time Objective) to maksymalny czas, w jakim system, aplikacja lub proces biznesowy musi wrócić do działania po awarii, katastrofie lub incydencie bezpieczeństwa. Po jego przekroczeniu przestój zaczyna powodować skutki, na które organizacja nie może sobie pozwolić. RTO liczy się „w przód” — od chwili zakłócenia do momentu, w którym usługa znów działa — i podaje zwykle w minutach, godzinach lub dniach. To jeden z dwóch głównych parametrów planu ciągłości działania i odtwarzania po awarii (BC/DR), obok RPO.
Jak ustala się RTO?
RTO nie wyznacza sam dział IT. Wartość bierze się z analizy wpływu na biznes (Business Impact Analysis, BIA). To w niej właściciele procesów mówią, jak długo dany proces może nie działać, zanim straty — finansowe, wizerunkowe czy prawne — zrobią się zbyt duże. Zwykle wygląda to tak:
- Spis systemów i zależności — co jest krytyczne i co od czego zależy. To wyznacza kolejność odtwarzania.
- BIA i klasyfikacja — każdy proces dostaje poziom ważności (tier) i dopuszczalny czas przestoju.
- Dobór technologii — do zadanego RTO dopasowuje się rozwiązanie. Minuty: replikacja synchroniczna i klaster active-active. Godziny: odtwarzanie z migawek lub kopii. Dłuższe okna: odtwarzanie z taśm lub chmury.
- Test — zmierzony czas odtworzenia (faktyczny RTA, Recovery Time Achieved) porównuje się z deklarowanym RTO.
Czym różni się RTO od RPO?
To dwa różne, uzupełniające się parametry:
- RTO dotyczy czasu przestoju — jak szybko trzeba przywrócić usługę. Liczony w przód od incydentu.
- RPO (Recovery Point Objective) dotyczy utraty danych — ile danych (liczonych w czasie) wolno stracić. Wyznacza, jak często trzeba robić kopie lub replikować. Liczony wstecz od incydentu, do ostatniego dobrego punktu odtworzenia.
Przykład: RPO = 15 min znaczy, że dane trzeba replikować co najwyżej co 15 minut; RTO = 1 h znaczy, że usługa ma wrócić w ciągu godziny. Niskie RTO zwykle wymusza też niskie RPO — szybkie odtworzenie nie ma większego sensu, jeśli przywracamy mocno przestarzałe dane.
RTO a MTD i WRT
RTO musi mieścić się w granicy MTD (Maximum Tolerable Downtime) — maksymalnego przestoju, po którym szkody robią się katastrofalne. RTO jest zawsze krótsze od MTD, bo zostawia zapas na pracę zespołów, sprawdzenie wszystkiego i przywrócenie pełnej funkcjonalności (ten etap to WRT, Work Recovery Time). W skrócie: RTO + WRT ≤ MTD.
Koszt a RTO
Im krótsze RTO, tym wyższy koszt i większa złożoność. Dążenie do RTO bliskiego zeru dla wszystkich systemów po prostu się nie opłaca. Dlatego systemy dzieli się na warstwy:
- Tier 1 (krytyczne) — RTO w minutach: replikacja, zapasowa infrastruktura w trybie gorącym, automatyczny failover.
- Tier 2 (ważne) — RTO do kilku godzin: replikacja asynchroniczna, środowisko warm-standby.
- Tier 3 (standardowe) — RTO od godzin do doby: odtwarzanie z kopii zapasowych.
Dlaczego RTO ma znaczenie dla bezpieczeństwa?
RTO często liczy się pod kątem awarii sprzętu, ale to incydenty bezpieczeństwa — przede wszystkim ransomware — najczęściej je przekraczają. Powód jest prosty: deklarowane RTO zakłada przywrócenie z czystej kopii. Przy ataku trzeba najpierw wykonać dodatkowe kroki, których zwykły plan awaryjny nie przewiduje:
- Ustalenie momentu kompromitacji — trzeba sprawdzić, od kiedy dane są zainfekowane, żeby nie przywrócić zaszyfrowanych lub podmienionych kopii. To wymaga telemetrii i logów z odpowiednio długą retencją.
- Sprawdzenie integralności kopii — atakujący celowo niszczą lub szyfrują backupy, w tym migawki i repozytoria. Niezmienne kopie (immutable backup) i izolacja sieciowa skracają realne RTO przy ransomware.
- Usunięcie zagrożenia przed odtworzeniem — przywracanie do nieoczyszczonego środowiska kończy się ponowną infekcją. Tu potrzebna jest współpraca z SOC i zespołem reagowania na incydenty (DFIR).
Dlatego realnie osiągalny czas odtworzenia (RTA) przy incydencie cyber bywa znacznie dłuższy niż RTO dla zwykłej awarii. Monitoring sieci, NDR i pełna telemetria skracają fazę wykrycia i analizy (MTTD/MTTR), a tym samym pomagają zmieścić odtwarzanie w założonych celach. Regularne, mierzone testy odtwarzania — także ze scenariuszami ransomware — to jedyny wiarygodny sposób, żeby sprawdzić, czy deklarowane RTO da się naprawdę osiągnąć.
Dowiedz się więcej
- Shadow IT — Shadow IT utrudnia kontrolę nad systemami, co może wydłużyć czas odtworzenia po awarii.
- RODO / GDPR — RODO wymaga ciągłości ochrony danych, więc RTO wpływa na szybkość przywrócenia usług.
