RPO

RPO (recovery point objective) to punkt w czasie, do którego dane muszą zostać odtworzone po awarii ^[1]. W praktyce parametr mówi, jak dużą utratę danych organizacja uznaje za dopuszczalną. Jeśli RPO wynosi dobę, ostatnia użyteczna kopia nie może być starsza niż 24 godziny. Polski standard NSC 7298 tłumaczy termin jako „punkt odtworzenia danych” i opisuje go jako moment w czasie określający stan danych, które zostaną odzyskane po awarii ^[3]. RPO ustala się razem z RTO, ale oba parametry mierzą co innego: RPO utratę danych, RTO długość przestoju.

Jak działa

Przewodnik NIST SP 800-34 opisuje RPO jako punkt w czasie sprzed zakłócenia, do którego można odtworzyć dane procesu biznesowego, biorąc pod uwagę najnowszą kopię zapasową ^[2]. Wszystko, co powstało po tej kopii, a przed awarią, przepada albo musi zostać wprowadzone ponownie. Z tego wynika prosta zasada: odstęp między kolejnymi kopiami nie może być dłuższy niż RPO.

Wartość RPO wyznacza się w analizie wpływu na działalność. W ujęciu NIST ta analiza określa dla każdego procesu trzy wielkości: maksymalny tolerowany czas przestoju (MTD), RTO i RPO ^[2]. NIST zaznacza, że w odróżnieniu od RTO punkt odtworzenia nie wchodzi w skład MTD. Zależy od tego, ile utraty danych proces jest w stanie znieść w trakcie odtwarzania ^[2].

Zależność między harmonogramem kopii zapasowych (backup) a RPO pokazuje schemat poniżej.

RYS. 1RPO a harmonogram kopii

Pojęcia pokrewne

RPO jest jednym z kilku parametrów, które razem opisują odporność procesu na przerwę. Tabela zestawia je według SP 800-34.

Pojęcie trafiło też do prawa Unii. Rozporządzenie wykonawcze 2024/2690, wydane do dyrektywy NIS2, posługuje się sformułowaniem „cele dotyczące punktu odzyskiwania” ^[4]. Rozporządzenie DORA dla sektora finansowego mówi o „akceptowalnym poziomie utraty danych” obok zakładanego czasu przywrócenia systemów ^[5]. W obu aktach chodzi o tę samą wielkość, którą w planie ciągłości działania zapisuje się jako RPO.

W WordPressie

Strona na WordPressie składa się z dwóch części: bazy danych z wpisami, komentarzami i ustawieniami oraz plików, czyli rdzenia, motywów, wtyczek, przesłanych mediów i plików konfiguracyjnych ^[6]. Dokumentacja podkreśla, że do pełnego odtworzenia typowej strony potrzebne są obie ^[6]. RPO trzeba więc spełnić dla bazy i dla plików jednocześnie, a obie kopie powinny pochodzić z mniej więcej tego samego momentu.

Dokumentacja WordPressa zaleca kopię raz w tygodniu dla stron o małej aktywności i codziennie dla stron często zmienianych ^[6]. Przełożone na RPO oznacza to utratę do tygodnia albo do doby treści. Dla bloga z jednym wpisem w miesiącu tygodniowy harmonogram zwykle wystarcza. Dla sklepu z zamówieniami przez całą dobę doba utraconych zamówień to utracone dane klientów, płatności i adresy wysyłki. W takim przypadku RPO dla bazy ustawia się znacznie krócej niż dla katalogu z mediami, który zmienia się rzadziej.

Dokumentacja zaleca też kopię bazy zawsze przed aktualizacją ^[6], na przykład przed aktualizacją rdzenia WordPressa. Taki zrzut można wykonać narzędziem WP-CLI:

# zrzut bazy przed aktualizacją, nazwa pliku z datą i godziną
wp db export kopia-$(date +%F-%H%M).sql

Na hostingu współdzielonym kopie robione przez usługodawcę często leżą na tym samym serwerze co strona. Dokumentacja zaleca przechowywanie od trzech do pięciu ostatnich kopii w różnych miejscach: na serwerze, w chmurze i na komputerze lokalnym ^[6].

Znaczenie

RPO jest obietnicą, którą da się sprawdzić dopiero w dniu awarii. Jeśli kopia z wczoraj okaże się uszkodzona, rzeczywisty punkt odtworzenia cofa się do kopii sprzed tygodnia. Dlatego SP 800-34 zaleca, by polityka kopii określała minimalną częstotliwość i zakres kopii, na przykład codzienne albo cotygodniowe, przyrostowe albo pełne. Te parametry zależą od krytyczności danych i od tego, jak często pojawiają się nowe informacje ^[2].

Szczególnie dotkliwa jest utrata danych po ataku ransomware. Gdy kopie są dostępne z tego samego konta co strona, atakujący może je zaszyfrować albo usunąć razem z danymi produkcyjnymi. Wtedy RPO przestaje obowiązywać, bo nie ma z czego odtwarzać. Odpowiedzią jest kopia niezmienna (immutable backup) albo kopia poza zasięgiem kont używanych na co dzień. SP 800-34 zaleca przechowywanie kopii poza siedzibą i wybór lokalizacji tak odległej, by ta sama katastrofa nie objęła obu miejsc ^[2].

Utrata danych osobowych bez możliwości ich odtworzenia może być także naruszeniem ochrony danych osobowych w zakresie dostępności.

Dobre praktyki

• Ustalać RPO dla każdego procesu osobno: dla zamówień, formularzy i treści redakcyjnych, a nie jednej liczby dla całego serwera.
• Dobrać częstotliwość kopii tak, by odstęp między nimi był krótszy niż RPO. Kopię bazy robić też przed każdą aktualizacją ^[6].
• Trzymać kilka kopii w różnych lokalizacjach, co najmniej jedną poza serwerem strony ^[6].
• Okresowo odtwarzać kopię w środowisku testowym (staging). Dopiero udane odtworzenie potwierdza, że deklarowane RPO jest osiągalne.
• Zapisać RPO w procedurze disaster recovery (DR) i w planie przywrócenia działania, obok RTO.

Historia i przykłady

Obecne rozumienie RPO w administracji amerykańskiej opiera się na SP 800-34 Rev. 1 z maja 2010 roku ^[2]. W pierwszej wersji tego przewodnika próg przestoju nazywano Maximum Allowable Outage (MAO); w rewizji 1 zastąpiło go pojęcie MTD, obok którego stoją RTO i RPO ^[2]. W Polsce termin „punkt odtworzenia danych” jako odpowiednik RPO podaje słownik NSC 7298 w wersji 1.0 z 1 września 2021 roku, wydany przez Pełnomocnika Rządu ds. Cyberbezpieczeństwa ^[3].