RPO, czyli ile danych możesz stracić

RPO (Recovery Point Objective) to maksymalna ilość danych, wyrażona w czasie, jaką firma może stracić bez poważnych konsekwencji. Jeśli RPO wynosi 24 godziny, akceptujesz, że po awarii wrócisz do stanu sprzed doby.

Najważniejsze jest to, że RPO nie jest parametrem systemu backupu, tylko decyzją biznesową, którą system backupu ma dopiero zrealizować. Kolejność bywa odwrotna i to jest błąd. Firma sprawdza, że kopie wykonują się raz na dobę, i wpisuje do procedury RPO 24 godziny, zamiast najpierw ustalić, ile naprawdę może stracić.

W praktyce RPO równa się odstępowi między kopiami. Backup uruchamiany codziennie o 22:00 oznacza RPO 24 godziny, a awaria o 21:30 kosztuje prawie pełny dzień pracy. Nie ma tu miejsca na negocjacje ani na dobrą wolę oprogramowania.

Warto się zatrzymać i policzyć, czym ta doba jest naprawdę. Weźmy firmę produkcyjną, w której przez ERP przechodzi około 400 dokumentów dziennie: faktury sprzedaży, dokumenty magazynowe, zamówienia do dostawców. Utrata doby to nie „brakuje kilku plików”. To 400 dokumentów, które ktoś musi wprowadzić po raz drugi, odtwarzając je z papieru, maili i pamięci. To dwa, trzy dni pracy działu, w trakcie których powstają nowe dokumenty, więc zaległość rośnie szybciej, niż da się ją nadrobić.

Jest jeszcze druga kategoria strat, o której się zapomina. Fakturę da się odtworzyć z systemu kontrahenta. Notatki z rozmowy telefonicznej wpisanej do CRM, ustaleń w wątku mailowym czy zmian w dokumencie na dysku współdzielonym nie odtworzy nikt. Te dane po prostu znikają.

RTO, czyli jak długo możesz nie działać

RTO (Recovery Time Objective) to maksymalny akceptowalny czas niedostępności systemu. Jeśli firma wytrzyma cztery godziny bez ERP, RTO wynosi cztery godziny.

Tu pojawia się najczęstszy błąd w liczeniu. RTO mierzy się od momentu awarii, a nie od momentu, w którym administrator klika „przywróć”. Na pełny czas składa się kilka etapów i tylko jeden z nich dotyczy samego odtwarzania danych:

• wykrycie awarii, czyli czas od zdarzenia do chwili, gdy ktoś kompetentny się o nim dowie
• decyzja o odtwarzaniu, bo najpierw zwykle próbuje się naprawić to, co padło
• przygotowanie sprzętu docelowego, jeśli pierwotny serwer nie nadaje się do użycia
• odtworzenie danych
• weryfikacja spójności, czyli sprawdzenie, czy baza wstaje i czy dane się zgadzają
• powrót użytkowników do pracy, przelogowanie, sprawdzenie integracji między systemami

Z naszego doświadczenia wynika, że samo odtwarzanie danych to często mniej niż połowa RTO. Jeśli monitoring wykrywa awarię po dwóch godzinach, a decyzja o odtwarzaniu zapada po kolejnej, RTO na poziomie czterech godzin jest już nieosiągalne, choćby backup był idealny. Dlatego przy krótkich czasach odtworzenia rozmowa o monitoringu infrastruktury jest częścią rozmowy o backupie, a nie osobnym tematem.

Czym różnią się RTO i RPO

Najprościej tak: RPO patrzy wstecz, do ostatniej dobrej kopii, a RTO patrzy w przód, do momentu powrotu do pracy. Jedno mówi, ile danych zniknie, drugie, jak długo potrwa cisza.

Te dwie liczby są od siebie niezależne i to zaskakuje najczęściej. Można mieć RPO 15 minut i RTO 24 godziny, jeśli kopie wykonują się co kwadrans, ale odtworzenie 20 TB z chmury trwa dobę. Można też mieć sytuację odwrotną: środowisko zapasowe gotowe do przełączenia w kwadrans, ale zasilane danymi z nocnego backupu. Dlatego ustala się je zawsze parami, nigdy osobno.

Policz swoje RTO, zanim je obiecasz

Tu wchodzi arytmetyka, której brakuje w większości materiałów na ten temat. Odtwarzanie danych jest ograniczone przepustowością najwęższego elementu na drodze między kopią a systemem docelowym. Nie licencją, nie deklaracją producenta, tylko fizyką łącza i dysków.

Weźmy typowy scenariusz: trzeba odtworzyć 2 TB danych.

Przez sieć 1 Gbit/s teoretyczne maksimum to 125 MB/s, realnie osiąga się od 80 do 100 MB/s. Odtworzenie 2 TB zajmie od sześciu do siedmiu godzin. Samych danych, bez przygotowania środowiska i bez weryfikacji.

Przez sieć 10 Gbit/s, przy storage, który po obu stronach wyrabia, mówimy o godzinie do półtorej. Ten warunek jest istotny, bo przy takich prędkościach wąskim gardłem przestaje być sieć, a staje się macierz źródłowa albo docelowa.

Z chmury po łączu 300 Mbit/s te same 2 TB to około osiemnastu godzin, przy założeniu, że całe łącze jest dostępne wyłącznie do odtwarzania, a firma w tym czasie nie korzysta z internetu do niczego innego. Kopia w chmurze świetnie realizuje zasadę „jedna kopia poza siedzibą” i nie ma nic wspólnego z RTO na poziomie czterech godzin.

Z taśmy LTO sam transfer bywa szybszy, niż większość osób zakłada, bo współczesne napędy czytają kilkaset MB/s. Problemem jest czas dostępu do nośnika. Jeśli kaseta leży w sejfie w innej lokalizacji, do RTO trzeba doliczyć dojazd.

Dochodzi do tego czynnik, który raz po raz zaskakuje: na appliance z deduplikacją odtwarzanie potrafi być wyraźnie wolniejsze niż zapis. Przy backupie na dysk trafiają tylko bloki, których jeszcze tam nie ma. Przy odtwarzaniu trzeba przeczytać wszystkie, a leżą porozrzucane, bo są współdzielone między wieloma kopiami, więc odczyt sekwencyjny zamienia się w losowy. Producenci sobie z tym radzą, jedni trzymają ostatnią pełną kopię poza deduplikacją, inni cachują metadane na flashu, więc skala różnicy zależy od konkretnego rozwiązania. Wniosek jest jeden: wydajność backupu i wydajność odtwarzania to dwie osobne liczby, a w materiałach marketingowych widać zwykle tylko tę pierwszą. Trzeba dopytać o drugą.

Wniosek jest prosty i warto go zapamiętać. RTO wylicza się z wolumenu danych podzielonego przez realną przepustowość najwolniejszego ogniwa, a potem dodaje się do tego etapy wymienione w poprzedniej sekcji. Wszystko inne to zgadywanie.

Błędy, które unieważniają nawet dobrze wyliczone RTO

Pierwszy już znasz: pominięcie czasu wykrycia awarii. RTO liczone od rozpoczęcia odtwarzania jest zawsze piękne i zawsze nieprawdziwe.

Drugi dotyczy retencji, a konkretnie ransomware. Atakujący rzadko szyfruje dane w dniu, w którym wchodzi do sieci. Zwykle spędza w środowisku od kilkunastu dni do kilku tygodni, rozpoznaje je i po drodze psuje albo usuwa kopie zapasowe. Jeśli trzymasz kopie przez siedem dni, a napastnik był w środku trzy tygodnie, wszystkie dostępne kopie mogą być bezużyteczne. Retencja musi być dłuższa niż realny czas niewykrytej obecności w sieci, a przynajmniej jedna kopia musi być niemodyfikowalna. Piszemy o tym szerzej we wpisie o backup storage.

Trzeci to nieprzetestowane odtwarzanie. RTO bez wykonanego testu odtworzenia nie jest parametrem, tylko przypuszczeniem. Test odpowiada na pytania, których nie da się wyliczyć na kartce: czy procedura jest kompletna, czy ktoś poza jedną osobą potrafi ją wykonać, czy baza po odtworzeniu w ogóle wstaje. Dla systemów krytycznych robimy to co kwartał, dla pozostałych raz na pół roku, a poza harmonogramem zawsze po większej zmianie w środowisku: migracji, wymianie storage, zmianie oprogramowania backupowego albo wyraźnym przyroście danych.

Czwarty to traktowanie snapshotów jako realizacji RPO. Snapshot powstaje w kilka sekund i pozwala szybko cofnąć nieudaną aktualizację, ale zwykle leży na tym samym storage co dane produkcyjne. Awaria macierzy zabiera dane i snapshoty jednocześnie. Wyjaśniamy tę różnicę w osobnym wpisie o snapshotach i backupie.

Piąty to mylenie SLA dostawcy z własnym RTO. Umowa gwarantująca reakcję w ciągu czterech godzin mówi o tym, kiedy ktoś zacznie zajmować się problemem. Nie mówi, kiedy system wróci.

Cztery scenariusze i co z nich wynika dla architektury

Poniższa tabela pokazuje, jak konkretne wartości RPO i RTO przekładają się na to, co fizycznie musi stać w serwerowni.

Żadna z tych wartości nie jest sama w sobie dobra ani zła, wszystko zależy od tego, co dany system robi. W hurtowni RTO na poziomie czterech godzin bywa komfortem, bo magazyn przez ten czas pracuje na dokumentach papierowych. Na linii produkcyjnej albo w sklepie internetowym godzina to już policzalna strata i rozmowa wygląda zupełnie inaczej.

Osobno warto powiedzieć o RPO równym zero, bo w wymaganiach pojawia się częściej, niż wynikałoby to z potrzeb. Zerową utratę danych zapewnia wyłącznie replikacja synchroniczna, w której zapis jest potwierdzany dopiero wtedy, gdy przyjmą go obie lokalizacje. Kosztuje najwięcej ze wszystkich rozwiązań, wymaga bardzo dobrego łącza i wprowadza opóźnienie przy każdym zapisie, więc obniża wydajność systemu produkcyjnego. Wdraża się ją dla jednego, dwóch najbardziej krytycznych systemów, nigdy dla całego środowiska.

Ile kosztuje skracanie RPO i RTO

Koszt nie rośnie liniowo. Ostatnie minuty są najdroższe i to jest najważniejsze, co trzeba wiedzieć przed rozmową o budżecie.

Skrócenie RPO z 24 godzin do 12, a często i do 6, to głównie zmiana harmonogramu i trochę więcej miejsca na kopie. Dokładasz pojemność, sprawdzasz, czy kopia mieści się w oknie i nie obciąża produkcji w godzinach pracy, i tyle. To rozmowa o kilkudziesięciu procentach kosztu systemu backupu, nie o nowej inwestycji.

Zejście do RPO na poziomie godziny wygląda już inaczej, choć na wykresie to tylko kolejny krok w lewo. Kopia wykonywana co godzinę w środku dnia roboczego musi być przyrostowa i na tyle lekka, żeby nie spowalniała systemu produkcyjnego. Każda kolejna kopia wydłuża też łańcuch odtwarzania, czyli podnosi RTO i ryzyko, że jedno ogniwo okaże się uszkodzone. Przy większych wolumenach zamiast zagęszczać backup przechodzi się na replikację, a to zmiana architektury, nie harmonogramu.

Skrócenie RTO z 24 godzin do 15 minut to zupełnie inna liga. Potrzebujesz drugiego środowiska w gotowości, więc zbliżasz się do podwojenia kosztu infrastruktury, i to zanim policzysz łącze między lokalizacjami.

Na rachunek składają się cztery pozycje. Pojemność na kopie, która rośnie wraz z częstotliwością backupu i długością retencji. Przepustowość łącza między lokalizacjami. Sprzęt w drugiej lokalizacji, który przez większość czasu nic nie robi. Praca administratorów przy utrzymaniu i regularnych testach, czyli pozycja pomijana w wycenach najczęściej, a wracająca co miesiąc.

Zdroworozsądkowe domknięcie tej rozmowy wygląda tak: koszt skrócenia RTO porównaj z kosztem godziny przestoju. Jeśli godzina postoju kosztuje firmę trzy tysiące złotych, a skrócenie RTO z ośmiu godzin do jednej wymaga inwestycji rzędu kilkuset tysięcy, to jest decyzja, którą trzeba umieć obronić liczbami, a nie poczuciem, że „lepiej mieć”. Bywa też odwrotnie, bo w firmie produkcyjnej godzina stojącej linii potrafi kosztować tyle, że dyskusja kończy się w pół minuty.

RPO i RTO ustala się osobno dla każdego systemu

Najczęstszy błąd organizacyjny to jedna wartość dla całej firmy. Efekt jest podwójnie zły: przepłacasz za ochronę serwera wydruku i jednocześnie nie doinwestowujesz ERP.

W praktyce wystarczą trzy poziomy. Systemy krytyczne, bez których firma nie zarabia, czyli ERP, systemy produkcyjne, sprzedaż online. Systemy ważne, których brak boli, ale da się przez pół dnia pracować obok nich, czyli poczta, CRM, dyski współdzielone. Systemy wspierające, gdzie doba przerwy nikogo nie zabije.

Sposób prowadzenia rozmowy z biznesem też ma znaczenie. Nie pytamy „jakie RPO chcecie”, bo odpowiedź zawsze brzmi „zero, oczywiście”. Pytamy, ile godzin postoju tego konkretnego systemu firma wytrzyma, zanim zacznie tracić pieniądze albo klientów, i co dokładnie dzieje się w tym czasie w poszczególnych działach. Taka odpowiedź jest już użyteczna, bo zawiera liczbę i uzasadnienie.

RPO, RTO i NIS2

Dyrektywa NIS2 wymaga zarządzania ciągłością działania, w tym backupu i odtwarzania po awarii. Bez zdefiniowanych, udokumentowanych i przetestowanych wartości RPO oraz RTO taki proces po prostu nie istnieje, jest tylko deklaracją.

Nasze stanowisko w tej sprawie jest niezmienne i mówimy je klientom wprost: nie projektujemy backupu pod audyt. Dobrze zaprojektowana infrastruktura spełnia wymagania NIS2 przy okazji, bo te wymagania to opisane językiem prawnym minimum inżynierskie, które i tak trzeba zrealizować. Jeśli szykujesz się do wdrożenia, zebraliśmy praktyczne kroki we wpisie o tym, jak przygotować się do NIS2.

Jak podchodzimy do tego u klientów

Zaczynamy od dwóch liczb, których zwykle nikt nie ma policzonych: wolumenu danych do odtworzenia i realnej przepustowości między kopią a środowiskiem docelowym. Na tej podstawie wyliczamy RTO osiągalne w obecnej infrastrukturze, bez żadnych zmian. Ta liczba bywa zaskoczeniem i wtedy zaczyna się właściwa rozmowa, bo dopiero wtedy wiadomo, o ile trzeba ją skrócić i ile to kosztuje.

Potem dzielimy systemy na poziomy krytyczności i projektujemy architekturę kopii zapasowych osobno dla każdego z nich, zamiast rozciągać najostrzejszy wymóg na całe środowisko. Na końcu testujemy odtwarzanie, bo do tego momentu wszystko, co ustaliliśmy, jest tylko dobrze uzasadnioną prognozą.

Trzy liczby, od których zacznij

Jeśli po tym artykule miałabyś zebrać tylko trzy rzeczy, to te. Po pierwsze, ile terabajtów zajmuje najważniejszy system i skąd trzeba by go odtwarzać. Po drugie, jaka jest realna przepustowość na tej drodze, zmierzona, nie wpisana w umowie z operatorem. Po trzecie, ile kosztuje godzina jego postoju. Pierwsze dwie liczby dają RTO, jakie masz dzisiaj. Trzecia mówi, czy to wystarczy.

Jeśli chcesz mieć te wyliczenia zrobione porządnie, odezwij się do nas. Policzymy realne RTO dla Twojego środowiska, a potem pokażemy, ile kosztuje skrócenie tej liczby do wartości, której naprawdę potrzebujesz.