RPO i RTO dla zarządu: ile danych i czasu firma może stracić

Na pytanie, co się stanie, jeśli serwer jutro rano nie wstanie, w małej firmie najczęściej słychać „mamy backup”. Kiedy dopytać, z której godziny jest ostatnia kopia i ile trwałoby przywrócenie systemu do pracy, zaczyna się szukanie osoby, która kiedyś to ustawiała. Kopia istnieje, ale nikt nie wie, co ona właściwie obiecuje.

Te dwie niewiadome mają swoje nazwy. RPO mówi, ile danych firma może stracić. RTO mówi, jak długo może czekać na powrót systemu. Obie liczby są decyzją biznesową, którą zarząd powinien podjąć świadomie, zanim informatyk dobierze do niej sprzęt i harmonogram.

Co oznaczają RPO i RTO

Amerykański NIST w przewodniku SP 800-34 o planowaniu ciągłości działania systemów definiuje RPO (Recovery Point Objective, docelowy punkt odtworzenia) jako punkt w czasie przed awarią, do którego dane procesu można odtworzyć z najnowszej kopii. W praktyce to odległość między ostatnią dobrą kopią a chwilą awarii. Jeśli kopia wykonuje się codziennie o 22:00, a serwer pada następnego dnia o 15:00, firma traci 17 godzin zmian: faktury, zamówienia, korekty magazynu, wszystko, co zespół wprowadził od rana.

RTO (Recovery Time Objective, docelowy czas odtworzenia) to według tego samego dokumentu maksymalny czas, przez jaki zasób może pozostawać niedostępny, zanim skutki dla procesów firmy staną się nie do przyjęcia. Liczy się od awarii do chwili, w której ludzie znów pracują. Nie do momentu, w którym skończyło się kopiowanie plików.

NIST dokłada trzecie pojęcie, o którym w małych firmach mówi się rzadko: MTD (Maximum Tolerable Downtime), czyli łączny przestój, który właściciel procesu jest gotów zaakceptować, biorąc pod uwagę wszystkie skutki. RTO musi zmieścić się w MTD z zapasem, bo po przywróceniu systemu trzeba jeszcze nadrobić zaległą pracę i wprowadzić ponownie utracone dane. RPO z kolei nie wchodzi do MTD, bo opisuje tolerancję procesu na utratę danych.

Dlaczego te liczby ustala zarząd

Informatyk wie, ile trwa odtworzenie bazy z kopii. Nie wie, ile kosztuje firmę dzień bez wystawiania faktur w ostatnim tygodniu miesiąca ani czy dział sprzedaży przetrwa cztery godziny bez dostępu do zamówień. NIST opisuje to wprost: dopuszczalny czas przestoju ustala się razem z właścicielami procesów i kierownictwem, a dopiero potem dobiera metody odtwarzania.

Ta sama logika stoi za normą ISO 22301, która opisuje wymagania wobec systemu zarządzania ciągłością działania. ISO podaje, że wymagania normy są ogólne i mają zastosowanie do organizacji każdego typu i rozmiaru. Mała firma nie musi się certyfikować, żeby skorzystać z jej podstawowej kolejności: najpierw skutki przestoju dla biznesu, potem cele odtworzenia, na końcu rozwiązania techniczne.

Odwrotna kolejność kończy się na dwa sposoby. Albo firma kupuje drogie rozwiązania, które chronią mało ważne systemy, albo zarząd zakłada, że „w razie czego wrócimy w godzinę”, podczas gdy obecna kopia pozwala wrócić po dwóch dniach.

Osobne cele dla każdego procesu

Jedno RPO i jedno RTO dla całej firmy prawie zawsze jest błędem. Poczta, system ERP, pliki projektowe i archiwum skanów mają różną wartość i różne tempo zmian. Rozsądniej podzielić procesy na trzy grupy:

• Krytyczne: ich zatrzymanie blokuje sprzedaż, wysyłkę, produkcję albo płatności.
• Ważne: przerwa jest kosztowna, ale przez ograniczony czas istnieje obejście, na przykład praca na papierze.
• Wspierające: można je przywrócić później bez zatrzymania głównej działalności.

Dla każdego procesu z pierwszych dwóch grup warto zapisać właściciela, systemy, od których zależy, dopuszczalną utratę danych, dopuszczalny przestój i obejście na czas awarii. Na tym materiale projektuje się potem kopie.

Przykład wyliczenia dla małej firmy

Poniższy przykład to typowy scenariusz ilustracyjny, z liczbami przyjętymi na potrzeby rachunku. Zakładamy firmę handlową zatrudniającą 15 osób: system ERP z bazą danych na serwerze w biurze, pliki na serwerze NAS, poczta w chmurze. Zarząd po rozmowie z kierownikami działów ustala takie cele:

Proces	Systemy	Skutek przestoju	RPO	RTO
Sprzedaż i fakturowanie	ERP, baza danych	Brak dokumentów, wstrzymana wysyłka	1 godzina	4 godziny
Dokumenty i oferty	Pliki na NAS	Utrudniona praca, częściowe obejście	4 godziny	1 dzień roboczy
Komunikacja	Poczta w chmurze	Utrudniony kontakt, telefon jako obejście	24 godziny	1 dzień roboczy
Archiwum skanów	NAS, folder archiwalny	Brak odczuwalnego skutku przez tydzień	24 godziny	5 dni roboczych

Te cele bezpośrednio wyznaczają harmonogram kopii:

• RPO 1 godzina dla ERP oznacza kopię bazy danych co najmniej co godzinę w czasie pracy. Kopia nocna tego celu nie spełni, bo w najgorszym razie odda dane sprzed kilkunastu godzin.
• RPO 4 godziny dla plików spełniają migawki (ang. snapshot, czyli zapisy stanu wolumenu w danym momencie) wykonywane na serwerze NAS co dwie godziny, z zapasem na nieudane zadanie.
• RPO 24 godziny dla poczty wystarczy dobowa kopia skrzynek do niezależnego miejsca.

RTO wyznacza z kolei, gdzie kopia musi leżeć i co musi być gotowe. Weźmy 2 TB danych do odtworzenia z chmury przez łącze 100 Mb/s. Nawet przy pełnym wykorzystaniu łącza samo pobranie trwa około 44 godzin (2 TB × 8 = 16 000 000 Mb, podzielone przez 100 Mb/s daje 160 000 sekund). Przy RTO 4 godziny dla ERP potrzebna jest więc kopia lokalna w biurze, sprzęt, na którym da się bazę uruchomić, i opisana procedura. Kopia w chmurze zostaje zabezpieczeniem na wypadek utraty całego biura.

Jak RPO i RTO przekładają się na koszt

Koszt przestoju w tym przykładzie łatwo przybliżyć w osobogodzinach. Cztery godziny bez ERP przy 15 osobach to do 60 osobogodzin pracy wstrzymanej lub wykonywanej na obejściach. Do tego dochodzi czas ponownego wprowadzenia danych z utraconej godziny oraz opóźnione wysyłki. Pensje i marżę Waszej firmy możecie podstawić w kalkulatorze kosztu przestoju.

Po drugiej stronie stoi koszt rozwiązania. NIST pokazuje to jako dwie krzywe: im dłużej trwa przerwa, tym więcej kosztuje firmę, a im krótsze RTO, tym droższe rozwiązanie odtworzeniowe. Punkt przecięcia jest inny w każdej organizacji. Orientacyjnie wygląda to tak:

Cel	Co zwykle trzeba mieć	Względny koszt
RPO 24 h, RTO kilka dni	Kopia nocna, odtwarzanie na sprzęt kupiony po awarii	Niski
RPO kilka godzin, RTO 1 dzień	Migawki w ciągu dnia, kopia lokalna i poza biurem, zapasowy dysk lub serwer	Średni
RPO 1 h, RTO kilka godzin	Częste kopie bazy, wirtualizacja, sprzęt gotowy do uruchomienia kopii, przećwiczona procedura	Wyższy
RPO i RTO w minutach	Replikacja na drugi serwer, automatyczne przełączanie, dyżur	Wysoki

Rozmowa o koszcie przestaje być wtedy abstrakcyjna. Zarząd porównuje koszt rocznego utrzymania wariantu z kosztem jednego realistycznego przestoju. Często okazuje się, że dla jednego systemu warto zapłacić za krótszy czas, a dla reszty firmy wystarcza wariant podstawowy.

Test zamienia cel w potwierdzoną możliwość

Dokument, który deklaruje RTO cztery godziny, jest tylko założeniem, dopóki nikt nie zmierzył pełnego odtworzenia. Amerykańska CISA w zestawie celów cyberbezpieczeństwa CPG 2.0 zaleca testowanie kopii i odtwarzania co najmniej raz w roku. CERT Polska w poradniku dotyczącym ransomware zwraca uwagę, że regularne testy pozwalają uniknąć sytuacji, w której mimo istniejących kopii nie da się odtworzyć stanu sprzed infekcji przez błąd w samej kopii.

Dobry test mierzy dwie rzeczy, które odpowiadają obu celom:

1. Czas. Od decyzji o odtworzeniu do chwili, w której użytkownik loguje się do systemu i wystawia dokument. To jest Wasze rzeczywiste RTO.
2. Punkt danych. Który ostatni dokument jest w odtworzonej bazie i z której godziny pochodzi. To potwierdza RPO.

Wynik porównuje się z celem. NIST przewiduje sytuację, w której celu nie da się od razu osiągnąć: wtedy rozbieżność zapisuje się w planie działań z terminami. Dla małej firmy to może być jedna strona z listą: czego brakuje, kto to zrobi i do kiedy.

Gdzie cel najczęściej rozjeżdża się z rzeczywistością

Przy pierwszym teście odtworzenia w małej firmie wychodzą zwykle te same rozbieżności. Żadna z nich nie jest widoczna w raporcie zadania kopii, każda wydłuża RTO albo psuje RPO.

• Kopia bazy wykonywana jak kopia plików. Pliki otwartej bazy danych skopiowane w trakcie pracy bywają niespójne. Kopia „się udała”, a baza po odtworzeniu nie startuje.
• Brak instalatora, licencji albo konfiguracji programu. Same dane bez aplikacji, która je odczyta, nie przywracają procesu.
• Hasło do kopii zna jedna osoba. Zaszyfrowana kopia bez klucza jest bezużyteczna, a klucz bywa w głowie byłego pracownika.
• Kopia stale podłączona do sieci. CERT Polska zaleca, by kopia nie była podłączona jako zasób sieciowy w sieci roboczej, bo wtedy złośliwe oprogramowanie szyfrujące może dosięgnąć jej razem z serwerem.

Każdą z tych rzeczy da się naprawić stosunkowo małym nakładem pracy, pod warunkiem że wyjdzie na jaw podczas spokojnego testu.

Karta decyzji dla zarządu

Na jednym arkuszu dla każdego procesu krytycznego i ważnego wystarczą następujące pola:

• nazwa procesu i jego właściciel po stronie biznesu,
• skutek przestoju po 1, 4, 8 i 24 godzinach,
• docelowe RPO i RTO,
• systemy, dane, ludzie i dostawcy potrzebni do przywrócenia, łącznie z hasłami i kluczami szyfrowania kopii,
• tryb awaryjny na czas przestoju,
• data ostatniego testu i zmierzony wynik,
• różnica między celem a potwierdzoną możliwością.

Taki arkusz nie wymaga specjalistycznego oprogramowania. Wymaga jednej rozmowy zarządu z kierownikami i jednego testu odtworzenia. Po tej rozmowie łatwiej też ocenić, czy obecna konfiguracja kopii, opisana szerzej we wpisie o backupie danych w firmie, w ogóle odpowiada potrzebom.

Od czego zacząć w Waszej firmie

Zacznijcie od jednego procesu, który najbardziej boli, gdy stoi. Ustalcie dla niego RPO i RTO, sprawdźcie, z której godziny pochodzi ostatnia kopia, i zmierzcie odtworzenie na osobnym sprzęcie. Z tego jednego testu dowiecie się więcej niż z miesięcy zielonych raportów „zadanie zakończone powodzeniem”.

Kiedy cele są znane, dobór kopii staje się zadaniem technicznym: ile kopii, na jakich nośnikach i gdzie, co opisujemy we wpisie o zasadzie 3-2-1. Serwery, wirtualizację i kopie projektujemy pod ustalone cele w ramach usługi serwery, selfhosting i backup.

Źródła

• NIST, SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, maj 2010, aktualizacja 11.11.2010, https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final (dostęp 2.10.2026)
• NIST Computer Security Resource Center, Glossary: Recovery Time Objective, https://csrc.nist.gov/glossary/term/recovery_time_objective (dostęp 2.10.2026)
• ISO, ISO 22301:2019 Security and resilience. Business continuity management systems. Requirements, https://www.iso.org/standard/75106.html (dostęp 2.10.2026)
• CISA, Cross-Sector Cybersecurity Performance Goals, Version 2.0, grudzień 2025, https://www.cisa.gov/cybersecurity-performance-goals-2-0-cpg-2-0 (dostęp 2.10.2026)
• CERT Polska, Poradnik ransomware, https://cert.pl/uploads/docs/CERT_Polska_Poradnik_ransomware.pdf (dostęp 2.10.2026)

Stan na 2 października 2026 r.