RTO
RTO (Recovery Time Objective) — maksymalny akceptowalny czas przywrócenia systemu po awarii, liczony od momentu incydentu do ponownej dostępności usługi. Kluczowy parametr Business Continuity Planning i Disaster Recovery.
Co to jest RTO?
RTO (Recovery Time Objective) to maksymalny akceptowalny czas przywrócenia systemu lub procesu biznesowego po awarii. Liczony od momentu wystąpienia incydentu do pełnej dostępności usługi — jest jednym z dwóch kluczowych parametrów Business Continuity Planning (obok RPO).
RTO w 30 sekund
- Co mierzy: czas od awarii do działającej usługi
- Jak jest wyrażone: godziny lub minuty (np. RTO = 4h)
- Kto ustala: BIA (Business Impact Analysis) + decyzja biznesowa + tradeoff kosztowy
- Dlaczego ważne: wyznacza architekturę DR i maksymalne dopuszczalne straty
RTO vs RPO vs MTTR — rozróżnienie
| Parametr | Co mierzy | Przykład |
|---|---|---|
| RTO | Czas przywrócenia (downtime max) | System online max 4h po awarii |
| RPO | Utrata danych (data loss max) | Utrata max 15 min transakcji |
| MTTR | Średni czas naprawy (historyczny) | Średnio naprawiamy w 2.5h |
| MTTF | Średni czas między awariami | System działa 10k godzin bezawaryjnie |
| MTTD | Średni czas wykrycia incydentu | Wykrywamy atak w 15 min |
RTO ≠ MTTR: RTO to cel (obietnica biznesowa), MTTR to pomiar historyczny. Organizacje powinny dążyć do MTTR < RTO.
Jak wyznaczyć RTO — Business Impact Analysis
Krok 1: Inwentaryzacja procesów biznesowych i systemów wspierających Krok 2: Oszacowanie strat finansowych per godzina downtime (utracony przychód, kary SLA, reputacja) Krok 3: Kategoryzacja krytyczności (Tier 0 = core, Tier 1 = ważne, Tier 2 = wspierające) Krok 4: Propozycja RTO per Tier (np. Tier 0 = 1h, Tier 1 = 4h, Tier 2 = 24h) Krok 5: Analiza kosztu osiągnięcia (active-active, warm standby, cold backup) Krok 6: Negocjacja z biznesem + zapis w BCP/DRP
Typowe wartości RTO per branża
| Branża / system | Typowe RTO |
|---|---|
| Systemy transakcyjne fintech | 15-30 min |
| Systemy płatności kartowych | <30 min |
| ERP core (produkcja) | 2-4h |
| CRM / sprzedaż | 4-8h |
| Systemy kadrowo-płacowe | 24h |
| Archiwalne / raportowe | 72h+ |
RTO a wymogi regulacyjne
- NIS2 (art. 21): proporcjonalne środki ciągłości — RTO 4-24h dla podmiotów ważnych i kluczowych
- DORA (fintech, art. 11): dokumentowane i testowane RTO/RPO dla funkcji krytycznych
- ISO 22301 (BCM): formalna metodyka wyznaczania RTO przez BIA
- KRI (sektor publiczny, Rozp. RM 2012): RTO wynikające z klasyfikacji zasobów
- PCI DSS (płatności): continuity plan z RTO/RPO dla systemów przetwarzających dane kartowe
Architektura DR a RTO — tradeoff kosztowy
- Cold standby (backup na taśmach/S3) → RTO 24-72h, koszt <10% produkcji
- Warm standby (DR site, dane replikowane, aplikacje stand-by) → RTO 2-8h, koszt 30-50%
- Hot standby (active-passive, ciągła replikacja, ręczny failover) → RTO 30min-2h, koszt 60-80%
- Active-active (multi-site, automatyczny failover, load balanced) → RTO <15min, koszt 100-150%
Sprawdź nasze usługi
Najczęściej zadawane pytania
+ Co to jest RTO?
RTO (Recovery Time Objective) to maksymalny akceptowalny czas, w którym system lub proces biznesowy musi zostać przywrócony po awarii — od momentu wystąpienia incydentu do pełnej dostępności. Jeśli RTO = 4h, a awaria trwa 6h, organizacja ponosi straty wykraczające poza akceptowalne. RTO jest kluczowym parametrem Business Continuity Planning.
+ Czym RTO różni się od RPO?
RTO (Recovery Time Objective) określa CZAS przywrócenia — ile maksymalnie może trwać downtime. RPO (Recovery Point Objective) określa ILOŚĆ DANYCH, które można stracić — ile godzin/minut sprzed awarii da się odzyskać. Przykład: RTO = 4h, RPO = 15min oznacza że przywracamy systemy w 4h i tracimy maksymalnie 15 minut transakcji. RPO decyduje o częstotliwości backupów, RTO o architekturze DR.
+ Jak wyznaczyć RTO dla systemu?
RTO wyznacza się w ramach Business Impact Analysis (BIA): (1) identyfikacja procesów krytycznych, (2) oszacowanie strat finansowych za godzinę downtime, (3) analiza kosztu odtworzenia (architektura HA, active-active, warm/cold standby), (4) negocjacja tradeoffu koszt vs akceptowalne straty z właścicielami biznesowymi. Typowe RTO: systemy krytyczne 15min-1h, ważne 4-8h, pozostałe 24h+.
+ Jakie RTO wymusza NIS2 i DORA?
NIS2 nie definiuje sztywnych RTO, ale art. 21 wymaga proporcjonalnych środków ciągłości działania — w praktyce KE rekomenduje RTO 4h dla systemów core. DORA (fintech) jest bardziej rygorystyczna: art. 11 wymaga polityki odtworzeniowej z dokumentowanymi RTO/RPO dla każdej funkcji krytycznej, testowanej corocznie. Dla systemów core w bankowości RTO zwykle 2-4h, płatności kartowe <30min.
+ Ile kosztuje osiągnięcie niskiego RTO?
Koszt rośnie geometrycznie z redukcją RTO. RTO 24h = standardowy backup + infrastruktura zapasowa = 10-30% kosztów produkcyjnej infrastruktury. RTO 4h = warm standby + DR site = 30-60%. RTO <1h = active-active multi-site replication = 80-150% kosztu produkcji. Decyzja powinna wynikać z BIA — jeśli godzina downtime kosztuje 500 tys. zł, RTO 4h oszczędza 2 mln/incydent i uzasadnia wydatki.