RTO (recovery time objective, docelowy czas odtworzenia) to najdłuższy czas, przez jaki system może być niedostępny po zakłóceniu. RPO (recovery point objective, docelowy punkt odtworzenia) to maksymalna ilość danych, jaką możesz stracić, mierzona jako czas od ostatniej użytecznej kopii. RTO wynoszące 4 godziny i RPO wynoszące 15 minut oznacza: powrót do działania w ciągu 4 godzin, ze stratą najwyżej 15 minut danych.
Najważniejsze wnioski
- RTO patrzy w przód od awarii (ile czasu do przywrócenia usługi). RPO patrzy wstecz (jak stara jest ostatnia dobra kopia danych).
- Oba parametry to decyzje biznesowe. Ustal je dla każdego systemu w analizie wpływu na biznes (business impact analysis), a potem wybierz technologię, która je spełni.
- Częstotliwość kopii zapasowych ogranicza Twoje RPO: przy kopiach co 4 godziny najgorszy przypadek utraty danych to około 4 godziny.
- Niższe cele kosztują więcej. Bliskie zera RTO/RPO wymaga replikacji i rezerwowych zasobów w drugiej lokalizacji.
- Cele na papierze znaczą niewiele, dopóki test nie zmierzy rzeczywistego czasu odtworzenia i utraty danych.
Czym jest RTO w odtwarzaniu po awarii?
RTO to maksymalny akceptowalny czas między wyłączeniem usługi a jej przywróceniem. AWS definiuje go jako „maksymalne akceptowalne opóźnienie między przerwaniem usługi a jej przywróceniem" w dokumencie Disaster Recovery of Workloads on AWS. NIST ujmuje go od strony biznesu: czas, przez jaki system może być w odtwarzaniu, „zanim negatywnie wpłynie to na misję organizacji lub jej procesy misji/biznesowe".
RTO obejmuje całe odtworzenie, a nie tylko techniczne przywrócenie. Wykrycie awarii, decyzja o uruchomieniu planu DR, przywrócenie danych, sprawdzenie aplikacji i przełączenie użytkowników liczą się do niego. Zespoły, które mierzą tylko samo przywracanie, zwykle nie dotrzymują RTO w prawdziwym zdarzeniu.
Czym jest RPO w odtwarzaniu po awarii?
RPO to maksymalna akceptowalna utrata danych, wyrażona w czasie. AWS nazywa go „maksymalnym akceptowalnym czasem od ostatniego punktu odtworzenia danych". Jeśli Twoje RPO wynosi 1 godzinę, to po awarii musisz móc przywrócić dane nie starsze niż 1 godzina.
RPO zależy od tego, jak często kopiujesz dane. Kopie nocne dają najgorszy przypadek RPO około 24 godzin. Kopie logów bazy danych co 15 minut dają mniej więcej 15 minut. Ciągła replikacja może zbliżyć je do zera, z jednym zastrzeżeniem opisanym niżej: replikacja kopiuje również uszkodzenia i usunięcia.
RTO a RPO: różnica w skrócie
| RTO | RPO | |
|---|---|---|
| Na jakie pytanie odpowiada | Jak długo możemy nie działać? | Ile danych możemy stracić? |
| Kierunek w czasie | W przód od awarii | Wstecz od awarii |
| Jak się mierzy | Czas przywrócenia usługi | Wiek ostatniego użytecznego punktu odtworzenia |
| Główne dźwignie | Zasoby rezerwowe, automatyzacja, infrastruktura jako kod, instrukcje operacyjne | Częstotliwość kopii zapasowych, replikacja, odtwarzanie do punktu w czasie |
| Typowy sposób porażki | Kroki ręczne, brak dostępów, DNS i zależności | Kopie, które po cichu zawodzą, lub repliki, które skopiowały uszkodzenie |
Przykłady obliczeń
Przykład 1: system zamówień. Sklep internetowy ustala RTO na 4 godziny i RPO na 15 minut. Baza danych ulega awarii o 10:00. Sklep musi znów przyjmować zamówienia do 14:00, a brakować może najwyżej zamówień złożonych między 09:45 a 10:00. Kopie nocne tego nie spełnią; sklep potrzebuje kopii logów transakcji lub replikacji co najmniej co 15 minut, a także skryptowego sposobu odbudowy warstwy aplikacji w ciągu 4 godzin.
Przykład 2: sprawdzenie harmonogramu kopii. System finansowy jest kopiowany co 6 godzin, a pełne przywrócenie trwa 3 godziny. Jeśli biznes oczekuje RPO 1 godzina i RTO 2 godziny, oba cele zawodzą: najgorszy przypadek utraty danych to około 6 godzin, a samo przywracanie przekracza RTO. Rozwiązaniem jest albo częstsze kopiowanie i szybsza metoda odtwarzania, albo decyzja biznesowa o poluzowaniu celów.
Przykład 3: podział portfela na poziomy. Większość firm grupuje systemy w poziomy zamiast ustalać cele jeden po drugim. Poniższe wartości są poglądowe, a nie standardem.
| Poziom | Przykładowe systemy | Poglądowe RTO | Poglądowe RPO | Prawdopodobna strategia DR |
|---|---|---|---|---|
| 1. Krytyczne dla misji | Płatności, platforma SaaS dla klientów | Minuty | Bliskie zera do minut | Warm standby lub multi-site active/active |
| 2. Krytyczne dla biznesu | ERP, CRM, obsługa zamówień | 1 do 4 godzin | 15 do 60 minut | Pilot light lub warm standby |
| 3. Ważne | Raportowanie, narzędzia wewnętrzne | 24 godziny | 24 godziny | Kopia zapasowa i przywracanie |
| 4. Niekrytyczne | Testy i rozwój | Dni | Dni lub odbudowa z kodu | Kopia zapasowa i przywracanie albo ponowne wdrożenie |
Kolumna strategii odpowiada czterem podejściom z dokumentu AWS, w którym kopia zapasowa i przywracanie zapewnia odtworzenie w godzinach, a multi-site active/active niemal w czasie rzeczywistym. Nasz przewodnik po planie odtwarzania po awarii wyjaśnia każdą strategię i sposób wyboru.
Jak RTO i RPO odnoszą się do maksymalnego tolerowanego przestoju?
Maksymalny tolerowany przestój (maximum tolerable downtime, MTD) to czas, przez jaki proces biznesowy może być zakłócony, zanim szkody staną się poważne. NIST SP 800-34 wyjaśnia, że RTO „zwykle musi być krótsze niż MTD", ponieważ gdy systemy wrócą, pracownicy nadal potrzebują czasu na nadrobienie zaległości i ponowne wprowadzenie utraconych danych. RPO nie jest częścią MTD. Opisuje, ile danych proces może sobie pozwolić stracić (NIST SP 800-34 Rev. 1).
W praktyce: jeśli proces zamówień może przetrwać 8 godzin bez systemów, a nadrobienie zaległości trwa 2 godziny, to RTO dla IT musi wynosić 6 godzin lub mniej.
Jak ustalić RTO i RPO
- Wypisz procesy biznesowe i ich zależności. Przypisz każdy proces do aplikacji, baz danych, usług tożsamości i podmiotów trzecich, których potrzebuje.
- Oszacuj wpływ przestoju i utraty danych w czasie. Przychody, kary umowne, ekspozycja regulacyjna, bezpieczeństwo i reputacja. AWS zwraca uwagę, że wpływ może zależeć od terminu: awaria systemu płac tuż przed dniem wypłaty znaczy znacznie więcej niż tuż po nim.
- Zaproponuj cele dla poszczególnych poziomów i pozwól właścicielowi biznesowemu je zatwierdzić. IT nie powinno wybierać ich samodzielnie.
- Wyceń opcje. AWS radzi, że jeśli strategia odtwarzania kosztuje więcej niż awaria, przed którą chroni, „nie należy jej wdrażać, chyba że istnieje dodatkowy powód, taki jak wymogi regulacyjne".
- Zaprojektuj i przetestuj. Zbuduj mechanizmy kopii zapasowych, replikacji i przełączenia awaryjnego, a następnie przeprowadź test i zapisz osiągnięty czas odtworzenia i punkt odtworzenia.
- Przeglądaj co roku i po większych zmianach. Systemy przesuwają się między poziomami wraz ze zmianami w biznesie.
Jakie technologie spełniają jakie cele?
- Zaplanowane kopie zapasowe i migawki pasują do RPO liczonych w godzinach. Dobrze chronią przed uszkodzeniem i usunięciem, bo każda kopia jest ustalonym punktem w czasie.
- Odtwarzanie do punktu w czasie (kopie logów bazy danych) obniża RPO do minut dla baz danych.
- Replikacja asynchroniczna do innego regionu daje RPO od sekund do minut, zależnie od opóźnienia replikacji.
- Replikacja synchroniczna między strefami dostępności daje RPO bliskie zera kosztem opóźnienia zapisu. Wytyczne Azure Well-Architected dotyczące odtwarzania po awarii sugerują replikację synchroniczną między strefami dla danych o wysokim priorytecie i asynchroniczną między regionami dla danych o niższym priorytecie.
- Środowiska rezerwowe i automatyzacja (pilot light, warm standby, infrastruktura jako kod, skryptowe przełączenie DNS) skracają RTO.
Uważaj na pułapkę replikacji. AWS zauważa, że ciągła replikacja „może nie chronić przed zdarzeniami awaryjnymi, takimi jak uszkodzenie danych lub złośliwy atak", tak dobrze jak kopie do punktu w czasie. Baza zaszyfrowana przez ransomware replikuje się równie szybko jak zdrowa, więc obok replik trzymaj kopie do punktu w czasie.
Jak udowodnić, że spełniasz swoje cele
Mierz, nie zakładaj. Podczas każdego testu DR zapisz, kiedy zaczęła się awaria, kiedy uruchomiono plan, kiedy usługa wróciła i jaki jest znacznik czasu ostatniej odzyskanej transakcji. Z tego wynikają osiągnięte RTO i RPO. Wytyczne Microsoftu zalecają mieszankę ćwiczeń przy stole (tabletop), prób na sucho w środowisku nieprodukcyjnym i ćwiczeń na poziomie produkcji. Śledź wyniki w czasie i najpierw popraw najwolniejszy krok.
Jak pomaga Opsio
Opsio prowadzi warsztaty analizy wpływu na biznes, ustala RTO/RPO dla poszczególnych poziomów razem z właścicielami biznesowymi oraz buduje i testuje odpowiadający im projekt odtwarzania w AWS i Azure w ramach swojej usługi odtwarzania po awarii w chmurze. W przypadku platformy SaaS do rekrutacji WorkBuster podejście z niemal zerowym przestojem było twardym wymogiem, gdy Opsio przenosiło platformę do AWS. Projekt wykorzystuje wysoko dostępną bazę danych MySQL w wielu strefach dostępności na Amazon RDS, z infrastrukturą zdefiniowaną w szablonach CloudFormation.
Najczęściej zadawane pytania
Jaka jest różnica między RTO a RPO?
RTO to czas, przez jaki system może być niedostępny po zakłóceniu. RPO to ilość danych, mierzona w czasie, jaką możesz sobie pozwolić stracić. RTO dotyczy przestoju, a RPO utraty danych.
Jakie są dobre RTO i RPO?
Nie ma uniwersalnej liczby. System płatności może wymagać minut dla obu, a wewnętrzne narzędzie raportowe może zaakceptować 24 godziny. Wyprowadź cele z kosztu przestoju i utraty danych dla każdego procesu biznesowego, a potem sprawdź koszt ich spełnienia.
Czy RPO może wynosić zero?
Blisko zera tak, przy replikacji synchronicznej lub projektach multi-site active/active. Prawdziwie zerową utratę danych trudno zagwarantować między regionami z powodu odległości i opóźnień, a sama replikacja nie chroni przed uszkodzeniem.
Czy RTO to to samo co SLA?
Nie. SLA to obietnica dla klientów dotycząca dostępności lub czasu reakcji. RTO to wewnętrzny cel odtworzenia dla scenariusza awarii. Twoje RTO powinno wspierać Twoje SLA, ale mierzy się je inaczej.
Jak często przeglądać cele odtwarzania?
Co najmniej raz w roku i po większych zmianach w systemach, u dostawców lub w biznesie. Mierz je ponownie w każdym teście DR, bo liczą się wartości osiągnięte.
Autor
Group COO & CISO
Fredrik jest COO i CISO grupy w Opsio. Koncentruje się na doskonałości operacyjnej, ładzie korporacyjnym i bezpieczeństwie informacji, ściśle współpracując z zespołami dostawczymi i kierowniczymi w celu uzgodnienia technologii, ryzyka i wyników biznesowych w złożonych środowiskach IT. Kieruje praktyką bezpieczeństwa Opsio, obejmującą usługi SOC, testy penetracyjne i ramy zgodności.
Zasady redakcyjne: Artykuł napisał wskazany powyżej specjalista od chmury. Aktualizujemy go, gdy zmienia się opisywana technologia lub regulacja; daty na tej stronie pokazują ostatnią aktualizację. Opsio zachowuje niezależność redakcyjną.