DRP i BCP

Czym jest RTO?

Q: Czym różni się RTO od MTD?

MTD (Maximum Tolerable Downtime) to łączny czas przestoju, jaki zarząd akceptuje dla danej działalności, z uwzględnieniem wszystkich skutków. RTO to czas przywrócenia działania zasobu informatycznego. NIST zaznacza, że RTO powinno być zasadniczo krótsze niż MTD, aby zostawić zapas na pozostałe etapy wznawiania działalności.

RTO (Recovery Time Objective, docelowy czas odtworzenia) to maksymalny czas, przez jaki usługa może pozostawać niedostępna. Mierzy się go od incydentu lub od decyzji o przełączeniu do chwili, gdy użytkownik ponownie wykona zwykłą czynność biznesową. Nie do momentu uruchomienia maszyny, na której aplikacja nie została jeszcze sprawdzona.

Aktualizacja: październik 20263 min czytania4 cytowane źródła

Najważniejsze

RTO to suma sześciu odcinków czasu: wykrycia, decyzji, odnalezienia dostępów, czasu technicznego, weryfikacji biznesowej i powrotu użytkowników.
NIST odróżnia je od maksymalnego tolerowanego czasu przestoju (MTD): RTO powinno być zasadniczo krótsze niż MTD.
RTO określa się dla każdej usługi: centrala telefoniczna i archiwum nie mają takiego samego.
Tylko test z pomiarem czasu pokazuje, czy zapisane RTO jest dotrzymywane.
Godziny pracy wsparcia i brak dyżurów są częścią rzeczywistego RTO.

Oficjalna definicja

Amerykański instytut NIST definiuje RTO jako maksymalny czas, przez jaki zasób systemu informatycznego może pozostawać niedostępny, zanim skutki staną się niedopuszczalne dla wspieranych przez niego procesów. Odróżnia je od maksymalnego tolerowanego czasu przestoju (MTD), czyli łącznego czasu przestoju, jaki zarząd akceptuje dla danej działalności. RTO ma gwarantować, że MTD nie zostanie przekroczony, dlatego zasadniczo jest krótsze.

ANSSI, francuska krajowa agencja ds. cyberbezpieczeństwa, używa pojęcia maksymalnego dopuszczalnego czasu przerwy (DMIA). Wymaga, aby strategia kopii zapasowych uwzględniała go dla każdego zasobu biznesowego oraz aby kolejność przywracania była ustalona z wyprzedzeniem, z uwzględnieniem zależności (DNS, usługa katalogowa…) i krytyczności aplikacji.

Z czego składa się RTO

W przypadku klasycznego przywracania:

czas potrzebny na zauważenie awarii;
czas na podjęcie decyzji i skontaktowanie się z osobą, która wie, co zrobić;
czas na odnalezienie kluczy, haseł i procedury;
techniczny czas kopiowania lub uruchamiania;
czas weryfikacji przez osobę z działu biznesowego;
czas, po którym stanowiska lub zdalni klienci odzyskują dostęp do usługi (DNS, VPN, IP).

RTO „dwie godziny” deklarowane przez oprogramowanie często obejmuje tylko etap 4, w warunkach laboratoryjnych. Rzeczywiste RTO to suma wszystkich sześciu. W nocy i w weekend sam etap 2 może przekroczyć dwie godziny, jeśli nikt nie pełni dyżuru.

W przypadku BCP etapy 4 i 6 są przygotowane z wyprzedzeniem. Pozostaje wykrycie oraz ryzyko, że nikt nie odważy się zatwierdzić przełączenia.

RTO i RPO nie są kartą przetargową wobec siebie

Można mieć krótkie RPO (częste kopie) i długie RTO (powolne przywracanie dużego wolumenu danych). Można też mieć krótkie RTO (środowisko zapasowe już uruchomione) i słabe RPO, jeśli środowisko zapasowe ma dwie godziny opóźnienia. Obie wartości trzeba zapisać.

RPOMaksymalna dopuszczalna utrata danych

RTOMaksymalny dopuszczalny czas przestoju

mierzone wstecz

mierzone naprzód

Dane sprzed incydentu

!Incydent

Ponowne uruchomienie usług

	RPO	RTO
Pytanie	Ile pracy możemy stracić?	Jak długo możemy pozostać bez działania?
Sposób pomiaru	Wstecz, od incydentu	Naprzód, od incydentu
Od czego zależy	Od częstotliwości kopii	Od przygotowania środowiska zapasowego
Jak to sprawdzić	Data ostatniej udanej kopii	Test z pomiarem czasu

Osobne RTO dla każdej usługi

Centrala telefoniczna i system zarządzania dokumentami archiwalnymi nie mają takiego samego RTO. Zapisanie „RTO 4 godziny” dla całej firmy oznacza albo przepłacanie za system dokumentów, albo nieprawdę w odniesieniu do centrali. Wystarczy jeden wiersz na usługę.

Jak sprawdzić, czy RTO jest dotrzymywane

Wyłącznie mierząc czas podczas testu. Jeśli test trwał sześć godzin, a zapisane RTO wynosi dwie godziny, to błędne jest zapisane RTO, dopóki architektura się nie zmieni. Nie „doąży się” do RTO, któremu przeczy ostatni pomiar. ANSSI kładzie na to nacisk: procedurę przywracania należy spisać i regularnie stosować. Częstotliwość testów omówiono w poradniku Jak często testować DRP?.

W WeDoBack

Na stronie nie publikujemy jednej liczbowej wartości RTO i wymyślanie jej byłoby wprowadzaniem w błąd: zależy ona od wolumenu danych, łącza, rozmiaru instancji i dostępności osób po stronie klienta. Architektura zmienia natomiast charakter tego czasu. Przy zwykłym przywracaniu trzeba sprowadzić dane i ewentualnie ponownie zainstalować system. W ramach DRP serwery uruchamiają się ponownie na instancjach zapasowych z wybranej wersji: czas techniczny to czas tego uruchomienia, a nie zakupu nowego serwera. Co miesiąc przeprowadzany jest test uruchomienia, bez wpływu na produkcję. W ramach BCP instancje chmurowe działają nieprzerwanie, a ruch jest przekazywany przez agenta w sieci klienta, bez zmiany adresu IP: pozostałe RTO to głównie czas wykrycia i decyzji. Replikacja lub synchronizacja danych między instancją BCP a serwerem źródłowym nie jest wbudowana: wymaga dedykowanego procesu, dostosowanego do potrzeb, który WeDoBack może wdrożyć na podstawie wyceny. We wszystkich trzech przypadkach weryfikacja biznesowa nadal wlicza się do mierzonego czasu. Wsparcie prowadzone przez ludzi jest dostępne w godzinach 9:00–13:00 i 14:00–17:30 (czasu paryskiego).

Poznaj DRP Poznaj BCP

Najczęściej zadawane pytania

Czym różni się RTO od MTD?

MTD (Maximum Tolerable Downtime) to łączny czas przestoju, jaki zarząd akceptuje dla danej działalności, z uwzględnieniem wszystkich skutków. RTO to czas przywrócenia działania zasobu informatycznego. NIST zaznacza, że RTO powinno być zasadniczo krótsze niż MTD, aby zostawić zapas na pozostałe etapy wznawiania działalności.

Oprogramowanie deklaruje RTO wynoszące kilka minut. Czy to realne?

Ta wartość obejmuje zazwyczaj tylko techniczny czas uruchomienia w warunkach laboratoryjnych. Nie uwzględnia wykrycia, czasu potrzebnego na skontaktowanie się z upoważnioną osobą ani weryfikacji przez użytkownika. Państwa rzeczywiste RTO to wartość zmierzona podczas ostatniego testu, od zgłoszenia incydentu do pierwszej udanej czynności biznesowej.

Czy RTO jest obowiązkiem prawnym?

Żaden przepis nie narzuca MŚP konkretnej wartości. RODO (art. 32) wymaga jednak środków pozwalających przywrócić dostępność danych osobowych i dostęp do nich „w odpowiednim czasie” w razie incydentu. RTO to konkretny sposób określenia tego odpowiedniego czasu.

Dowiedz się więcej

Źródła

Dokumenty sprawdzone w październiku 2026 r.

SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
Kopie zapasowe systemów informatycznych – podstawy (ANSSI-BP-100, v1.1, 27 listopada 2025, w języku francuskim) — ANSSI (agencja francuska)
Rozporządzenie (UE) 2016/679 (RODO), art. 32 — EUR-Lex
Oferta DRP (plan odtwarzania po awarii) — WeDoBack

Planują Państwo projekt kopii zapasowych, DRP lub BCP?

Ponad 20 lat doświadczenia w ochronie danych firmowych.

Poproś o wycenę +33 9 72 50 78 28

Proszę chronić swoje dane z WeDoBack

Szyfrowana kopia zapasowa poza siedzibą firmy, niezmienna pamięć masowa, DRP i BCP: proszę opisać nam swoje serwery, a zaproponujemy właściwe połączenie rozwiązań.

Poproś o wycenę Zobacz ofertę i cennik