Co to jest RPO i RTO? Wartości, różnice i sposób wyliczenia

RPO (Recovery Point Objective) to maksymalna ilość danych, jaką firma godzi się utracić – wyrażona w czasie, który minął od ostatniej kopii. RTO (Recovery Time Objective) to maksymalny czas, w jakim system ma wrócić do działania po awarii. RPO odpowiada na pytanie „ile danych przepadnie”, RTO na pytanie „jak długo nie da się pracować”. Poniżej znajdują się definicje obu wskaźników, typowe wartości dla systemów spotykanych w średnich firmach oraz sposób wyliczenia własnych progów.

Co oznaczają skróty RPO i RTO?

RPO i RTO to dwa niezależne parametry planowania odtwarzania. Pierwszy opisuje dopuszczalną stratę danych, drugi dopuszczalny czas przestoju. Oba ustala się przed awarią, na podstawie tego, ile kosztuje godzina niedostępności konkretnego systemu – a nie po awarii, kiedy jedyne, co można zrobić, to zmierzyć rzeczywisty wynik.

RPO (Recovery Point Objective)

RPO wyznacza punkt w przeszłości, do którego da się cofnąć dane po awarii. Jeśli kopia wykonuje się raz na dobę o północy, a awaria zdarzy się o 15:00, przepada piętnaście godzin pracy. RPO tego systemu wynosi 24 godziny – i tyle danych trzeba założyć jako stratę.

W praktyce RPO przekłada się wprost na jedną decyzję: jak często wykonywać kopie. Krótsze RPO oznacza częstsze kopie albo replikację, a to podnosi koszt infrastruktury.

RTO (Recovery Time Objective)

RTO to czas liczony od momentu awarii do chwili, w której system znów działa. Obejmuje wykrycie problemu, decyzję o uruchomieniu procedury, samo odtworzenie i weryfikację. Jeśli RTO systemu magazynowego wynosi cztery godziny, po tym czasie magazyn ma wznowić wydania – a nie dopiero zacząć przywracanie z kopii.

Częsty błąd polega na tym, że w RTO liczy się wyłącznie czas kopiowania plików. Wykrycie awarii w nocy potrafi zająć więcej niż samo odtworzenie.

Inne znaczenia skrótów RPO i RTO

Oba skróty są w polszczyźnie wieloznaczne, co bywa źródłem nieporozumień przy wyszukiwaniu informacji.

RPO poza informatyką oznacza najczęściej Rzecznika Praw Obywatelskich, a także Regionalny Program Operacyjny w kontekście funduszy unijnych oraz Recruitment Process Outsourcing w branży kadrowej.

RTO bywa skrótem od regeneracyjnego dopalacza termicznego (Regenerative Thermal Oxidizer) stosowanego w przemyśle oraz od Regional Transport Office w krajach anglojęzycznych. Podobnie brzmiący RTOS to system operacyjny czasu rzeczywistego.

W dalszej części artykułu oba skróty występują wyłącznie w znaczeniu związanym z odtwarzaniem danych.

RPO a RTO – czym się różnią

Najkrócej: RPO mierzy dane, RTO mierzy czas. RPO zależy od tego, jak często powstaje kopia. RTO zależy od tego, jak szybko da się ją odtworzyć i uruchomić system. Oba wskaźniki wyraża się w jednostkach czasu, co bywa mylące, ale mierzą zupełnie różne rzeczy.

Cecha	RPO	RTO
Na co odpowiada	ile danych wolno stracić	jak długo system może nie działać
Punkt odniesienia	moment ostatniej kopii przed awarią	moment przywrócenia działania po awarii
Co wyznacza w praktyce	częstotliwość kopii lub replikacji	sposób i kolejność odtwarzania, zasoby zapasowe
Od czego zależy technicznie	harmonogram backupu, typ replikacji, CDP	wydajność odtwarzania, automatyzacja, gotowość środowiska zapasowego
Kto powinien ustalać	właściciel procesu biznesowego wspólnie z IT	właściciel procesu biznesowego wspólnie z IT

 

Warto zapamiętać jedną rzecz, o której rzadko się pisze: RPO i RTO nie są ze sobą powiązane matematycznie. RTO może wynosić 24 godziny przy RPO na poziomie 15 minut i odwrotnie. System archiwalny może wymagać rzadkich kopii, ale szybkiego dostępu. Baza transakcyjna odwrotnie – danych nie wolno stracić prawie wcale, a kilka godzin przestoju bywa akceptowalne.

Jakie wartości RPO i RTO przyjąć w firmie

Nie istnieje jedna poprawna wartość. Progi ustala się osobno dla każdej grupy systemów, według tego, jak szybko ich niedostępność zaczyna kosztować. Poniższa tabela pokazuje przedziały spotykane na rynku – są punktem wyjścia do rozmowy, nie normą.

Klasa systemu	Przykłady	RTO	RPO	Dostępność
Krytyczny dla przychodu	sklep internetowy, sprzedaż, sterowanie produkcją	poniżej 1 h	poniżej 15 min	99,99%
Krytyczny operacyjnie	ERP, WMS, CRM, księgowość	do 4 h	do 1 h	99,95%
Wspierający	poczta, intranet, systemy kadrowe	do 24 h	do 4 h	99,9%
Archiwalny	archiwa, raporty historyczne, środowiska testowe	do 72 h	do 24 h	99,5%

 

Podział wygląda technicznie, ale decyzja jest biznesowa. Magazyn, który nie może wydać towaru, wstrzymuje dostawy do klientów. Nieczynny system kadrowy przez jeden dzień zwykle nie robi różnicy. Dlatego przypisanie systemu do klasy powinno wynikać z rozmowy z osobami odpowiedzialnymi za proces, a nie z konfiguracji serwera.

MTD i WRT – dwa wskaźniki pomijane w większości opracowań

RPO i RTO nie opisują całego czasu potrzebnego na powrót do normalnej pracy. Brakuje dwóch elementów: granicy, po przekroczeniu której straty stają się nieodwracalne, oraz czasu potrzebnego na uporządkowanie danych po odtworzeniu systemu.

MTD (Maximum Tolerable Downtime) to maksymalny czas przestoju, jaki organizacja jest w stanie znieść bez trwałych konsekwencji – utraty klientów, kar umownych, zatrzymania produkcji. RTO musi być od MTD wyraźnie krótsze, bo między przywróceniem systemu a powrotem do normalnej pracy zwykle mija jeszcze trochę czasu.

WRT (Work Recovery Time) to właśnie ten czas: uzupełnienie danych z okresu, którego nie objęła kopia, weryfikacja poprawności, ręczne wprowadzenie dokumentów. W magazynie oznacza to przeliczenie stanów. W księgowości – ponowne zaksięgowanie dokumentów z ostatnich godzin.

Pominięcie WRT jest najczęstszym powodem, dla którego odtworzenie formalnie zgodne z RTO i tak kończy się dniem straconej pracy. System działa, ale dane w nim nie odpowiadają rzeczywistości, więc nikt nie może na nim polegać.

Od czego technicznie zależy RPO

RPO wynika bezpośrednio z zastosowanej technologii ochrony danych. Im krótszy dopuszczalny odstęp między kopiami, tym droższe i bardziej złożone rozwiązanie. Poniższe zestawienie pokazuje rzędy wielkości, których można się spodziewać.

Technologia	Osiągalne RPO	Uwagi
Backup w harmonogramie dobowym	godziny lub doby	najtańsze rozwiązanie, wystarczające dla systemów archiwalnych
Backup częstszy, z kopiami przyrostowymi	godziny	standard dla systemów wspierających
Replikacja asynchroniczna	minuty do godzin	dane trafiają do drugiej lokalizacji z opóźnieniem, bez wpływu na wydajność systemu produkcyjnego
Replikacja synchroniczna	bliskie zeru	zapis potwierdzany w obu lokalizacjach jednocześnie, kosztem ograniczenia odległości między ośrodkami
CDP, czyli ciągła ochrona danych	sekundy	producenci podają kilkanaście sekund jako wartość realistyczną przy większym obciążeniu

 

Dobór technologii warto zacząć od tabeli klas systemów, a nie od katalogu producenta. Więcej o samych rozwiązaniach opisano we wpisach o backupie w chmurze (https://itcenter.pl/backup-w-chmurze-vs-tradycyjne-metody-co-wybrac-dla-twojej-firmy/) oraz o platformie Veeam (https://itcenter.pl/co-to-jest-veeam-backup/).

RPO i RTO a plan ciągłości działania

RPO i RTO są parametrami wejściowymi planu ciągłości działania, a nie samym planem. Plan opisuje, kto podejmuje decyzje, w jakiej kolejności odtwarzane są systemy i skąd biorą się zasoby zapasowe. Bez ustalonych wartości RPO i RTO plan nie ma według czego priorytetyzować.

Zależność działa w obie strony. Zbyt ambitne progi bez pokrycia w infrastrukturze tworzą plan, którego nie da się wykonać. Progi ustawione zbyt luźno oznaczają, że w krytycznym momencie nikt nie wie, czy sytuacja mieści się jeszcze w normie.

Szerzej temat omawia osobny wpis o planie Disaster Recovery (https://itcenter.pl/disaster-recovery-plan-drp-wyjasniamy-jak-radzic-sobie-z-naglymi-awariami-systemu/). Firmy, które nie chcą utrzymywać własnego środowiska zapasowego, korzystają z modelu Disaster Recovery as a Service (https://itcenter.pl/co-to-jest-draas-disaster-recovery-as-a-service/).

Dlaczego deklarowane RPO i RTO zwykle nie są prawdziwe

Wartość, której nie potwierdzono testem odtworzenia, jest deklaracją, nie parametrem. Wpisana do dokumentacji liczba mówi tylko tyle, że ktoś ją kiedyś ustalił. Czy da się ją dotrzymać, wiadomo dopiero po próbie – a takich prób robi się w Polsce niewiele.

Z badania przeprowadzonego wśród polskich firm wynika, że tylko 20 procent regularnie testuje pełne odtwarzanie danych z kopii zapasowej, a 30 procent nie testuje wcale lub robi to sporadycznie. Jednocześnie 74 procent menedżerów IT przyznaje, że obawia się niezawodności własnego backupu. Wśród barier wskazywano brak czasu i zasobów oraz brak środowiska testowego (badanie polskiego rynku backupu i ciągłości działania, 2026).

Rzeczywiste czasy odtwarzania są przy tym znacznie dłuższe, niż zakłada większość dokumentacji. Z analizy publicznie raportowanych awarii w 2025 roku wynika, że 28 procent z nich trwało ponad 48 godzin, a tylko 12 procent udało się zamknąć w cztery godziny (Uptime Institute, Annual Outage Analysis 2026).

Przy odtwarzaniu po ataku ransomware skala jest jeszcze inna. Mediana pełnego powrotu do normalnej pracy wynosi trzy tygodnie, choć 55 procent organizacji odzyskuje dostęp do systemów w ciągu tygodnia (Sophos, The State of Ransomware 2026). Kluczowe okazuje się to, czy napastnik zdołał naruszyć same kopie zapasowe – gdy mu się to udaje, mediana kosztu odtworzenia rośnie ośmiokrotnie, z 375 tysięcy do 3 milionów dolarów (Sophos, badanie z 2024 roku).

Warto też zestawić deklaracje z przygotowaniem organizacyjnym. Kompleksowe plany ciągłości działania przygotowuje 35 procent organizacji działających w Polsce, a aktualną listę procesów krytycznych ma 38 procent (KPMG, Barometr cyberbezpieczeństwa 2026).

Rozsądny rytm weryfikacji wygląda następująco:

• automatyczne sprawdzenie poprawności kopii po każdym wykonaniu,
• test odtworzenia pojedynczych plików lub bazy raz w miesiącu,
• test odtworzenia całej aplikacji wraz z zależnościami raz na kwartał,
• pełna próba scenariusza awaryjnego, z pomiarem rzeczywistego RTO, co pół roku do roku.

Dopiero po takim teście można powiedzieć, że RPO i RTO są parametrami, a nie założeniami.

RPO i RTO w umowie SLA oraz w wymaganiach regulacyjnych

W umowach z dostawcami usług IT RTO bywa mylone z czasem reakcji. To dwie różne wartości: czas reakcji mówi, kiedy ktoś zacznie się problemem zajmować, RTO – kiedy system ma znów działać. Zapis o dostępności na poziomie 99,9 procent również nie określa RTO, bo mówi wyłącznie o dopuszczalnej sumie przestojów w skali roku, nie o czasie pojedynczego odtworzenia.

Przy negocjowaniu umowy warto więc pytać wprost o trzy rzeczy: czas reakcji, deklarowane RTO dla konkretnej usługi oraz to, czy dostawca potwierdza je testem odtworzenia.

Wymagania regulacyjne idą w tę samą stronę, choć nie podają liczb. Zarówno przepisy wdrażające dyrektywę NIS2, jak i rozporządzenie DORA w sektorze finansowym wymagają zdefiniowania celów odtwarzania i regularnego testowania procedur, pozostawiając wybór konkretnych wartości organizacji. Oczekuje się, że progi wynikną z analizy ryzyka i będą udokumentowane. Temat obowiązków w obszarze cyberbezpieczeństwa rozwija osobny wpis o dyrektywie NIS2 i centrum operacji bezpieczeństwa (https://itcenter.pl/czy-w-dobie-dyrektywy-nis2-twoja-firma-musi-miec-soc/).

Jak ustalić RPO i RTO w konkretnej firmie

Sensowne progi powstają w czterech krokach, a każdy z nich wymaga rozmowy poza działem IT.

Krok pierwszy – spis systemów i procesów. Nie lista serwerów, tylko lista tego, co firma robi: przyjmowanie zamówień, wydania z magazynu, fakturowanie, obsługa reklamacji. Do każdego procesu przypisuje się systemy, które go obsługują.

Krok drugi – wycena godziny przestoju. Dla każdego procesu trzeba oszacować, ile kosztuje godzina jego niedostępności: wstrzymana sprzedaż, przestój linii, kary umowne, koszt pracy ludzi, którzy nie mogą pracować. Nie musi to być precyzyjna kalkulacja – rząd wielkości wystarczy, żeby uszeregować systemy.

Krok trzeci – przypisanie klasy. Na podstawie kosztu przestoju każdy system trafia do jednej z klas z tabeli powyżej. Ten etap zwykle ujawnia, że kilka systemów uznawanych za krytyczne w rzeczywistości może poczekać, a jeden traktowany jako poboczny zatrzymuje cały łańcuch.

Krok czwarty – weryfikacja testem. Bez tego kroku trzy poprzednie pozostają teorią.

Na koniec jedna uwaga o kosztach przestoju: nie rosną liniowo. Pierwsza godzina niedostępności systemu magazynowego oznacza opóźnione wydania. Doba oznacza już przesunięte dostawy, zerwane terminy u odbiorców i koszty, które pojawiają się długo po przywróceniu systemu.

Wsparcie w zakresie ciągłości działania

Ustalenie RPO i RTO to punkt wyjścia. Dalej potrzebne są rozwiązania, które te wartości realnie zapewnią, oraz regularna weryfikacja, że nadal działają.

ITCenter projektuje i utrzymuje środowiska ochrony danych dla średnich firm. Zakres obejmuje analizę wpływu potencjalnej awarii na działalność, rozwiązania klasy business continuity, backup lokalny i w chmurze, replikację oraz Disaster Recovery w modelu usługowym. Opracowywane są także scenariusze przywracania danych, czyli praktyczne odwzorowanie założonych wartości RPO i RTO. Wdrożenia opierają się na rozwiązaniach Veeam, Acronis oraz NAKIVO. Szczegóły dostępne są na stronie ciągłość operacyjna i dane (https://itcenter.pl/oferta/bezpieczenstwo/ciaglosc-operacyjna-i-dane/).

Firmy, które chcą zacząć od sprawdzenia stanu obecnego, mogą skorzystać z audytu systemów informatycznych (https://itcenter.pl/oferta/bezpieczenstwo/kontrola-i-audytowanie-it/) – obejmuje on również audyt zgodności z wymaganiami prawnymi, regulacyjnymi i branżowymi.

Najczęstsze pytania o RPO i RTO

Co to jest RPO i RTO?

RPO (Recovery Point Objective) to maksymalna ilość danych, jaką firma godzi się utracić, wyrażona jako czas od ostatniej kopii. RTO (Recovery Time Objective) to maksymalny czas przywrócenia systemu do działania po awarii. Pierwszy wskaźnik wyznacza częstotliwość kopii, drugi sposób odtwarzania.

Czym różni się RPO od RTO?

RPO mierzy dane, RTO mierzy czas. RPO odpowiada na pytanie, ile pracy przepadnie po awarii, RTO – jak długo system pozostanie niedostępny. Oba podaje się w jednostkach czasu, ale dotyczą różnych rzeczy i ustala się je niezależnie.

Co oznacza wskaźnik RPO?

RPO wskazuje punkt w przeszłości, do którego można odtworzyć dane. Przy kopii wykonywanej raz na dobę RPO wynosi 24 godziny, co oznacza ryzyko utraty całego dnia pracy. Im krótsze RPO, tym częstsze kopie lub replikacja.

Co mierzy RTO?

RTO mierzy czas od wystąpienia awarii do momentu, w którym system znów działa. Obejmuje wykrycie problemu, decyzję o uruchomieniu procedury, odtworzenie danych i weryfikację poprawności – nie tylko samo kopiowanie plików.

Jakie są typowe wartości RPO i RTO dla systemu ERP?

Systemy klasy ERP, WMS i CRM zwykle trafiają do kategorii krytycznych operacyjnie, z RTO do czterech godzin i RPO do godziny. Wartości te są punktem odniesienia – realne progi wynikają z kosztu godziny przestoju w konkretnej firmie.

Czy RPO musi być mniejsze niż RTO?

Nie. RPO i RTO są niezależne. Możliwa jest sytuacja, w której RTO wynosi 24 godziny, a RPO 15 minut – tak bywa przy systemach, gdzie dane są bezcenne, ale przestój da się przeczekać. Zdarza się też odwrotnie.

Czy sam backup wystarczy, żeby spełnić założone RPO i RTO?

Backup zabezpiecza RPO, czyli ogranicza utratę danych. Nie gwarantuje RTO, ponieważ odtworzenie z kopii bywa długie. Krótkie RTO wymaga dodatkowo gotowego środowiska zapasowego i przećwiczonej procedury przełączenia.

Jak często testować odtwarzanie, żeby wiedzieć, że RTO jest realne?

Automatyczna weryfikacja kopii po każdym wykonaniu, test odtworzenia pojedynczych danych raz w miesiącu, test całej aplikacji raz na kwartał i pełna próba scenariusza awaryjnego co pół roku do roku. W Polsce pełne odtwarzanie testuje regularnie tylko co piąta firma.

Co oznacza skrót RPO poza informatyką?

Najczęściej Rzecznika Praw Obywatelskich, a także Regionalny Program Operacyjny w kontekście funduszy unijnych oraz Recruitment Process Outsourcing w branży kadrowej. W kontekście IT RPO oznacza wyłącznie Recovery Point Objective.