RTO

RTO (recovery time objective) to łączny czas, przez jaki komponenty systemu mogą pozostawać w fazie odtwarzania, zanim przestój zacznie szkodzić misji organizacji albo jej procesom biznesowym ^[1]. Mówiąc prościej, RTO określa, jak długo strona, sklep czy system może nie działać. Polski standard NSC 7298 tłumaczy termin jako „czas odzyskiwania” i opisuje go jako czas potrzebny do przywrócenia systemu do pracy, w tym do odzyskania danych ^[3]. RTO ustala się w parze z RPO: RPO mówi, ile danych można stracić, RTO – ile czasu można stracić.

Jak działa

Przewodnik NIST SP 800-34 definiuje RTO jako maksymalny czas, przez który zasób systemu może być niedostępny, zanim wpływ na inne zasoby, wspierane procesy i MTD stanie się nie do przyjęcia ^[2]. MTD, czyli maksymalny tolerowany czas przestoju, to całkowity czas przerwy w procesie, który właściciel systemu jest gotów zaakceptować ^[2].

Z tych definicji wynika kolejność. Ponieważ RTO ma zapewnić, że MTD nie zostanie przekroczony, RTO musi zwykle być krótsze niż MTD ^[2]. Różnicę wypełniają czynności po uruchomieniu systemu, na przykład ponowne przetworzenie danych, których nie zdążono obsłużyć przed awarią ^[2]. Wartości ustala się w analizie wpływu na działalność, a zapisuje w planie ciągłości działania.

Czas liczony w RTO obejmuje kilka etapów, które pokazuje schemat poniżej.

RYS. 1Co mieści się w RTO

RTO, RPO i MTD

Trzy parametry często są mylone, bo wszystkie wyraża się w jednostkach czasu. Tabela zestawia ich znaczenie według SP 800-34.

Pojęcie występuje także w prawie Unii. Rozporządzenie wykonawcze 2024/2690, wydane do dyrektywy NIS2, wymienia „maksymalny dopuszczalny czas przestoju” i „cele dotyczące czasu przywrócenia normalnego działania” ^[4]. Rozporządzenie DORA mówi o określeniu w sposób elastyczny „zakładanego czasu przywrócenia systemów” ^[5].

W WordPressie

Na RTO strony WordPress składają się głównie trzy rzeczy: dostępność aktualnej kopii zapasowej (backup), czas jej odtworzenia i czas sprawdzenia, że strona jest czysta. Dokumentacja WordPressa nazywa kopie krytycznym elementem ciągłości działania. Radzi też zapytać firmę hostingową o jej politykę kopii ^[6]. Jeśli kopia istnieje, właściciel powinien móc odtworzyć stronę i przejść do analizy włamania ^[6].

Odtworzenie bazy przez phpMyAdmin polega na wybraniu bazy, zakładki importu i pliku kopii w formacie SQL ^[7]. Podręcznik uprzedza, że import dużej bazy trwa ^[7]. Rozmiar bazy i przepustowość serwera wprost wydłużają więc RTO. Po włamaniu dochodzi czyszczenie. Dokumentacja zaleca ponowne wgranie katalogów /wp-admin i /wp-includes w tej samej wersji, której używa strona, przez FTP albo SFTP, a nie przez opcję reinstalacji w panelu ^[6]. To zadania, które najlepiej przećwiczyć wcześniej, zanim będą liczone w godzinach przestoju sklepu.

Zanim zacznie się sprzątanie, dokumentacja radzi wykonać jeszcze jedną kopię zainfekowanego środowiska jako materiał porównawczy ^[6]. Ten krok wydłuża RTO, ale chroni przed utratą śladów potrzebnych w czyszczeniu przejętej strony.

Znaczenie

Wybór RTO jest decyzją kosztową. SP 800-34 opisuje to jako bilans dwóch krzywych: im dłużej trwa przerwa, tym więcej kosztuje organizację, ale im krótsze RTO, tym droższe rozwiązania odtwarzania ^[2]. System, który musi wrócić natychmiast, wymaga rozwiązań bez przestoju i zapasowego ośrodka. System o mniejszym znaczeniu i dłuższym RTO może poprzestać na prostszej kopii ^[2]. Punkt równowagi jest inny dla każdej organizacji i każdego systemu ^[2].

Gdy RTO nie da się od razu dotrzymać, a MTD jest sztywne, NIST zaleca spisanie planu działań naprawczych z terminami ^[2]. Dla właściciela sklepu internetowego MTD bywa krótkie, bo każdy dzień przerwy to utracona sprzedaż. Dla strony wizytówkowej dłuższy przestój jest zwykle do przyjęcia.

Najczęstszą przyczyną nagłego testu RTO jest ransomware albo inna forma złośliwego oprogramowania (malware), po której stronę trzeba odtworzyć od zera. W takim scenariuszu czas odtworzenia wydłuża się o prace, których nie widać w prostym teście kopii: szukanie czystej kopii sprzed infekcji, zmianę haseł i sprawdzenie, czy atakujący nie zostawił tylnej furtki (backdoor). Dokumentacja WordPressa zaleca zmianę haseł do wszystkich punktów dostępu, w tym FTP i SFTP, panelu WordPressa, panelu hostingu i bazy MySQL ^[6]. Zaleca też wymianę kluczy w pliku wp-config.php, która wylogowuje wszystkie aktywne sesje ^[6]. Plan, który pomija te kroki, w praktyce przekroczy założone RTO.

Dobre praktyki

• Ustalić RTO dla każdego procesu osobno i sprawdzić, czy jest krótsze niż MTD ^[2].
• Zapisać procedurę odtwarzania krok po kroku w planie disaster recovery (DR): gdzie leżą kopie, kto ma dostęp, w jakiej kolejności przywracać bazę i pliki.
• Zmierzyć rzeczywisty czas odtworzenia na środowisku testowym (staging), a nie przyjmować go z założenia.
• Włączyć odtwarzanie do procesu reagowania na incydenty, tak by decyzja o przywróceniu z kopii zapadała w ustalonym trybie.
• Po odtworzeniu sprawdzić nie tylko stronę główną, ale też logowanie, formularze i płatności. Dopiero wtedy przywrócenie działania jest zakończone.

Historia i przykłady

SP 800-34 Rev. 1 ukazał się w maju 2010 roku ^[2]. Pierwsza wersja przewodnika opisywała próg przestoju jako Maximum Allowable Outage (MAO), a w rewizji 1 ten próg nosi nazwę MTD ^[2]. Polski odpowiednik „czas odzyskiwania” podaje słownik NSC 7298 w wersji 1.0 z 1 września 2021 roku ^[3].