RTO i RPO: ile przestoju i utraty danych Twoja firma naprawdę wytrzyma?

„Mamy backup” to najczęstsza odpowiedź na pytanie o plan awaryjny. Kłopot w tym, że samo istnienie kopii nie mówi nic o tym, jak szybko firma wróci do pracy i ile danych przepadnie po drodze. Do tego służą dwa wskaźniki: RTO i RPO. Bez nich trudno sensownie zaprojektować kopie zapasowe, replikację czy drugą lokalizację — i trudno rozliczyć dostawcę, gdy coś pójdzie nie tak.

Czym są RTO i RPO?

RTO (Recovery Time Objective) to maksymalny czas, w jakim system ma wrócić do działania po awarii. Odpowiada na pytanie: jak długo możemy nie działać?

RPO (Recovery Point Objective) to maksymalna ilość danych, liczona w czasie, którą firma jest w stanie utracić. Odpowiada na pytanie: z którego momentu musimy móc odtworzyć dane? Jeśli RPO wynosi godzinę, kopia lub replika nie może być starsza niż godzina.

Te dwie wartości są od siebie niezależne. Archiwum dokumentów może znieść kilka dni przestoju, ale nie może stracić ani jednego pliku. Serwis informacyjny musi wstać w kilka minut, ale utrata ostatnich komentarzy nikogo nie zaboli. Dlatego RTO i RPO wyznacza się osobno dla każdego systemu, a nie raz dla całej firmy.

Jak wyznaczyć RTO i RPO dla swoich systemów

To nie jest decyzja działu IT. Liczby muszą wyjść od biznesu, a IT ma powiedzieć, ile kosztuje ich dotrzymanie.

Krok 1: zrób listę systemów i ich właścicieli

Sklep internetowy, ERP, poczta, system kadrowy, serwer plików, aplikacje wewnętrzne. Przy każdym wpisz osobę, która odpowiada za proces biznesowy, a nie tylko za serwer.

Krok 2: policz skutki przestoju i utraty danych

Dla każdego systemu zadaj trzy pytania: ile tracimy na każdej godzinie niedostępności, czy po pewnym czasie pojawiają się kary umowne lub obowiązki wobec regulatora, oraz czy brakujące dane da się odtworzyć ręcznie (np. z maili, papierowych dokumentów, systemu partnera).

Krok 3: przypisz systemy do klas

Zamiast dziesiątek indywidualnych wartości wystarczą zwykle trzy–cztery klasy, np. „krytyczne”, „ważne” i „pozostałe”. Każda klasa dostaje swoje RTO i RPO, a wraz z nimi konkretny sposób ochrony.

Od liczb do architektury

Im krótsze RTO i RPO, tym droższe rozwiązanie. Warto to powiedzieć wprost, zanim zarząd zażąda „zera minut i zera danych” dla wszystkiego.

• Dłuższe RTO i RPO (dzień lub więcej): regularny backup na osobną przestrzeń dyskową i udokumentowana procedura odtworzenia. W Sprint Data Center można do serwera dokupić powierzchnię pod backup — kopia powinna jednak żyć poza maszyną, którą chroni.
• Średnie wartości (godziny): częstsze kopie przyrostowe, kopie baz danych z logami transakcji oraz zapasowy serwer gotowy do uruchomienia. Pomaga w tym sieć wewnętrzna między serwerami, po której kopie i repliki przesyłane są poza publicznym internetem.
• Krótkie RTO i RPO (minuty): replikacja danych w czasie zbliżonym do rzeczywistego i drugi serwer gotowy do przejęcia ruchu. Tu nie wystarczy sam sprzęt — przełączenie trzeba regularnie sprawdzać, o czym piszemy w tekście o teście przełączenia awaryjnego.

Pamiętaj też, że backup i disaster recovery to nie to samo. Kopia chroni dane, ale nie odpowiada na pytanie, gdzie i na czym system zostanie uruchomiony. Szerzej opisujemy to w artykule Backup to nie disaster recovery, a o kopiach w innym miejscu niż serwer produkcyjny — w tekście o kopii zapasowej w drugiej lokalizacji.

Infrastruktura, która nie przeszkadza w dotrzymaniu celów

RTO liczy się od momentu awarii do przywrócenia usługi. Do tego czasu wlicza się wszystko: wykrycie problemu, dojazd technika, wymianę podzespołu, odtworzenie danych. Dlatego środowisko, w którym pracują serwery, ma bezpośredni wpływ na to, czy cele są realne.

W centrum danych Sprint Data Center w Olsztynie serwery pracują przy dwutorowym zasilaniu z UPS i agregatem prądotwórczym, zespół techniczny jest dostępny przez całą dobę, 365 dni w roku, a certyfikat ISO 22301 potwierdza wdrożony system zarządzania ciągłością działania. Przy kolokacji do dyspozycji jest usługa remote hands — technicy na miejscu mogą zrestartować serwer czy wymienić podzespół bez czekania na Twój przyjazd — oraz zdalne zarządzanie przez KVM over IP. Każda z tych rzeczy skraca czas, który inaczej trzeba by doliczyć do RTO.

Lokalizacja ma też znaczenie dla RPO. Jeśli Twoje główne środowisko działa we własnej serwerowni, kopia lub replika w zewnętrznym data center albo na serwerze dedykowanym daje dane, które przetrwają awarię całego budynku.

Sprawdź, czy Twoje RTO i RPO są realne

Zapisane cele to dopiero połowa pracy. Jedynym dowodem, że da się je dotrzymać, jest próba: odtwórz system z kopii, zmierz czas od startu do działającej usługi i sprawdź, z którego momentu pochodzą odtworzone dane. Jak zaplanować taki test, opisujemy w artykule Kiedy ostatnio odtwarzałeś dane z kopii zapasowej?. Jeśli wynik jest gorszy niż założenia — trzeba zmienić albo architekturę, albo oczekiwania biznesu.

Podsumowanie

RTO mówi, jak długo firma może nie działać, a RPO — ile danych może stracić. Wyznacz je razem z właścicielami procesów, przypisz systemy do klas i dopiero wtedy dobieraj backup, replikację i zapasowe serwery. Infrastruktura w profesjonalnym data center skraca czas reakcji na awarię, ale cele trzeba regularnie weryfikować testem odtworzenia.

Chcesz dobrać rozwiązanie do swoich RTO i RPO — od powierzchni pod backup, przez serwer zapasowy, po kolokację własnego sprzętu? Skontaktuj się z zespołem Sprint Data Center i porozmawiajmy o Twoim scenariuszu awaryjnym.

FAQ – najczęściej zadawane pytania o RTO i RPO

Czym różni się RTO od RPO?

RTO określa, jak szybko system musi wrócić do działania po awarii, a RPO — z którego momentu muszą pochodzić odtworzone dane, czyli ile danych można stracić. Pierwszy wskaźnik dotyczy czasu przestoju, drugi utraty danych. Oba wyznacza się osobno dla każdego systemu.

Czy codzienny backup wystarczy, żeby spełnić RPO?

Tylko wtedy, gdy firma akceptuje utratę danych z niemal całego dnia. Kopia wykonywana raz na dobę oznacza, że awaria tuż przed kolejnym backupem zabiera dane od poprzedniej kopii. Dla systemów transakcyjnych zwykle potrzebne są częstsze kopie przyrostowe lub replikacja.

Kto w firmie powinien ustalać RTO i RPO?

Wartości powinni zatwierdzić właściciele procesów biznesowych i zarząd, bo to oni wiedzą, ile kosztuje przestój i utrata danych. Dział IT przedstawia, jakie rozwiązania pozwolą dotrzymać tych celów i ile będą kosztować, a potem odpowiada za ich wdrożenie i testy.

Jak sprawdzić, czy deklarowane RTO jest realne?

Przeprowadź test odtworzenia: uruchom system z kopii lub przełącz ruch na serwer zapasowy i zmierz czas do pełnego działania usługi. Wynik porównaj z założeniem. Taki test warto powtarzać po każdej większej zmianie w infrastrukturze, a nie tylko raz przy wdrożeniu.

Czy data center może pomóc skrócić RTO?

Tak, bo część czasu przestoju to reakcja na awarię sprzętu. W Sprint Data Center zespół techniczny pracuje całą dobę, a w kolokacji dostępna jest usługa remote hands, dzięki czemu restart lub wymiana podzespołu nie czeka na przyjazd Twojego administratora.

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.