RPO (Recovery Point Objective)

RPO (Recovery Point Objective), czyli docelowy punkt przywracania, to maksymalna ilość danych — mierzona w czasie — jaką organizacja godzi się stracić po awarii, katastrofie lub ataku. Inaczej mówiąc: do jak dawnego momentu musimy umieć odtworzyć dane, żeby strata była do przyjęcia. RPO wyznacza maksymalną dopuszczalną „lukę” między ostatnią dobrą, możliwą do odtworzenia kopią a chwilą awarii — a przez to mówi nam, jak często trzeba robić kopie zapasowe lub replikować dane.

Prosty przykład: jeśli system ma RPO = 4 h, kopie lub replikacja muszą działać na tyle często, żeby w najgorszym razie stracić nie więcej niż 4 godziny zmian. RPO to jeden z dwóch głównych parametrów planu ciągłości działania i odtwarzania po awarii (BCDR). Drugim jest RTO.

Czym różni się RPO od RTO?

RPO i RTO (Recovery Time Objective) mierzą dwie różne rzeczy i łatwo je pomylić:

• RPO — ile danych możemy stracić. Patrzy wstecz, od awarii do ostatniej dobrej kopii. Decyduje o tym, jak często robimy kopie i replikację.
• RTO — jak długo usługa może nie działać. Patrzy w przód, od awarii do przywrócenia działania. Decyduje o architekturze odtwarzania, redundancji i procedurach.

Oba parametry są od siebie niezależne. System może mieć krótkie RPO (strata kilku minut danych) i jednocześnie długie RTO (godziny przywracania) — albo odwrotnie. Pokrewny wskaźnik to MTTR (Mean Time To Recovery), czyli średni rzeczywisty czas naprawy mierzony po fakcie. RTO jest celem, a MTTR mówi, ile naprawa naprawdę zajmuje.

Jak wyznacza się RPO?

RPO nie wybiera się „na czuja”. Wynika z analizy wpływu na biznes (BIA, Business Impact Analysis) i z tego, jakie to dane. Zwykle przechodzi się przez kilka kroków:

1. Podział systemów według ważności. Różne aplikacje różnie znoszą utratę danych. Przypisanie ich do warstw (tier) pozwala nie narzucać jednego, drogiego RPO całemu środowisku.
2. Ocena tempa zmian danych. Im więcej transakcji w danym czasie, tym więcej kosztuje każda stracona minuta i tym krótsze (bardziej rygorystyczne) musi być RPO.
3. Wymogi prawne i umowne. Branże takie jak finanse czy ochrona zdrowia bywają związane normami i umowami SLA, które narzucają konkretne progi.
4. Możliwości infrastruktury i budżet. Krótsze RPO to więcej operacji kopiowania, a więc większe zużycie pasma, pamięci i mocy obliczeniowej. Cel musi być realny technicznie i finansowo.

Zasada jest prosta: zbyt długie RPO grozi dotkliwą utratą danych, a zbyt krótkie generuje koszty bez proporcjonalnej korzyści. Dlatego RPO ustala się osobno dla każdej warstwy, a nie jednakowo dla całej organizacji.

Jakie technologie pozwalają osiągnąć dane RPO?

Wartość RPO zależy wprost od tego, jak często i jaką metodą chronimy dane:

• Klasyczne kopie zapasowe (np. raz na dobę) — najtańsze, ale dają RPO rzędu kilkunastu–24 godzin, bo między kolejnymi kopiami narasta luka zmian.
• Kopie przyrostowe i migawki (snapshots) — częstsze punkty odtworzenia (np. co kilka–kilkanaście minut) i mniejsze obciążenie niż pełne kopie.
• Replikacja (asynchroniczna lub synchroniczna) — kopiowanie zmian do drugiej lokalizacji. Replikacja synchroniczna pozwala zbliżyć RPO do zera, ale kosztem opóźnień i pasma.
• Ciągła ochrona danych (CDP, Continuous Data Protection) — zapis każdej zmiany na bieżąco, co daje RPO bliskie zeru (sekundy).

Dobrą praktyką wspierającą RPO jest reguła 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, z jedną kopią trzymaną poza lokalizacją produkcyjną.

Przykładowe wartości RPO według ważności systemu

RPO mocno różni się między warstwami systemów. Poniższe liczby to typowe rzędy wielkości, a nie sztywne normy:

• Systemy krytyczne dla biznesu (np. transakcje finansowe) — od bliskiego zeru do kilku minut; zwykle replikacja synchroniczna lub CDP.
• Systemy ważne (np. aplikacje produkcyjne, e-commerce) — od kilku minut do kilku godzin.
• Systemy wspierające (np. narzędzia wewnętrzne) — kilka–kilkanaście godzin.
• Dane archiwalne lub rzadko zmieniane — 24 godziny i więcej.

Dlaczego RPO jest istotne dla bezpieczeństwa?

RPO to już nie tylko parametr na wypadek awarii sprzętu. Dziś jest ważnym elementem odporności na ataki, zwłaszcza ransomware. Jest tu kilka niuansów, które generyczne opisy często pomijają:

• RPO nie chroni przed skażonymi kopiami. Jeśli atakujący siedział w sieci dni lub tygodnie, zanim uruchomił szyfrowanie, krótkie RPO może oznaczać odtworzenie najnowszej — ale już zainfekowanej — kopii. Dlatego RPO trzeba łączyć z retencją starszych, czystych punktów odtworzenia.
• Kopie niemodyfikowalne (immutable / WORM) oraz odizolowane repozytoria (air-gap) są warunkiem, żeby deklarowane RPO dało się utrzymać po ataku. Napastnicy często celują w same systemy backupu, by uniemożliwić odtworzenie.
• Wczesne wykrycie skraca rzeczywistą lukę. Im szybciej SOC lub NDR wykryje włamanie (wyciek danych, ruch boczny w sieci, początek szyfrowania), tym świeższy jest ostatni zaufany punkt odtworzenia — czyli tym bliżej realnie osiąganego RPO. Telemetria sieciowa i wykrywanie anomalii wprost wpływają na to, do którego momentu można bezpiecznie wrócić.
• RPO bez sprawdzenia to fikcja. Deklarowany cel ma wartość dopiero po regularnych testach odtwarzania (recovery drills) i weryfikacji, że kopie są spójne i wolne od złośliwego kodu.

Dowiedz się więcej

• Błędy DNS i bezpieczeństwo DNS – DNSSEC, ochrona przed atakami DNS i DNS management errors — Błędy DNS mogą wydłużyć przerwę w usługach i zwiększyć utratę danych między kopiami.
• Monitoring sieci i network visibility – analiza ruchu sieciowego jako podstawa visibility cybersecurity — Widoczność sieci pomaga szybciej wykryć awarię i ograniczyć utratę danych do punktu odtworzenia.
• DORA — DORA wymaga odporności operacyjnej, a RPO określa dopuszczalną utratę danych po incydencie.