Ustalenie celów dotyczących czasu odzyskiwania ma kluczowe znaczenie, zwłaszcza gdy rośnie liczba włamań do sieci i ataków ransomware. Nigdy nie wiesz, kiedy będziesz kolejną ofiarą. W tym momencie, jeśli docelowy czas odzyskiwania nie jest zdefiniowany, w jaki sposób możesz opracować plan tworzenia kopii zapasowych i odzyskiwania danych?
Ten post przeprowadzi Cię przez podstawy RTO i czynniki, o których należy pamiętać podczas ustawiania RTO.
Co to jest docelowy czas odzyskiwania?
Docelowy czas odzyskiwania (RTO) jest definiowany jako maksymalny akceptowalny czas, przez jaki aplikacja może być niedostępna lub maksymalny tolerowany przestój, jaki organizacja może wytrzymać bez powodowania znacznych szkód dla firmy po wystąpieniu katastrofy, awarii lub innego niedopuszczalnego zdarzenia.
Czas RTO sugeruje czas potrzebny na odzyskanie i zakończenie przywracania uszkodzonego systemu, zgodnie z umową dotyczącą poziomu usług. Cel poziomu usług uwzględnia czas przywracania ustawiony przez organizację w celu przywrócenia/przywrócenia krytycznych procesów/operacji IT do stanu normalnego od momentu wystąpienia awarii w celu zapewnienia ciągłości biznesowej.
Pro Tip: Zawsze należy dążyć do osiągnięcia najniższego możliwego RTO, aby zminimalizować skutki katastrofy. Aby określić RTO, musisz najpierw określić wpływ czasu trwania na Twoją firmę, w którym dane są niedostępne.
Na przykład:
- Jeśli 10% danych musi być dostępnych w ciągu 24 godzin,
- A po całkowitej utracie bazy 50% danych musi być dostępnych w ciągu 2 dni,
- Pozostałe 40% danych musi być dostępne w ciągu najbliższych 5 dni, wtedy
Twój całkowity RTO wynosi = 8 dni.
Aby przytoczyć inny przykład:
Załóżmy, że serwer Exchange jest wyłączony. Jeśli RTO wynosi 5 godzin, maksymalny tolerowany czas przestoju, który Twoja firma może przetrwać, wynosi 5 godzin, a RTO dla serwera Exchange musi być krótszy niż 5 godzin. Zasady odzyskiwania po awarii muszą obejmować niezbędne kroki podjęte przez dział IT w celu utworzenia kopii zapasowej i przywrócenia danych.
Dlatego przy ustalaniu czasu do odzyskania, nie ma jednego uniwersalnego rozwiązania dla plan ciągłości działania. RTO można ustawić na odzyskiwanie danych po wystąpieniu katastrofy. Jednak w przypadku wystąpienia incydentu praktyczne aspekty planu odzyskiwania po awarii zależą również od określonych narzędzi i technologii zastosowanych do zapewnienia odzyskiwania. Tak więc zdolność do trafienia w RTO jest różna, ponieważ różne technologie i narzędzia DR różnią się swoimi możliwościami. RTO jest mierzony jeszcze przed rozpoczęciem awarii i obejmuje czas potrzebny na naprawę serwerów, instalację aplikacji priorytetowych i przywracanie danych. Zawiera również metody odzyskiwania i dane z kopii zapasowej, które należy odzyskać.
Co określa RTO?
Docelowy czas odzyskiwania to docelowy czas trwania, w którym aplikacje, systemy i/lub procesy przetrwają przestój i nie działają przed rozpoczęciem zakłóceń. RTO ma ogromne znaczenie przy określaniu czasu potrzebnego na nadanie priorytetu aplikacjom i procesom w ramach parametrów RTO. W planie ochrony danych i strategii odzyskiwania po awarii, RTO odpowiada na pytanie „jaki jest ustalony docelowy czas przywrócenia usług po powiadomieniu o zakłóceniu usługi?”
RTO mogą określić:
- Czas trwania w czasie rzeczywistym, który należy ustawić w celu odzyskania witryny od momentu, w którym incydent przerywa normalny przepływ operacji do momentu przywrócenia
- Jakie przygotowania informatyczne należy przygotować do wdrożenia planu odtwarzania po awarii
- Dopuszczalny poziom ryzyka utraty danych, gdy system lub kluczowe aplikacje przechodzą w tryb offline.
Jak obliczyć RTO dla planowania odzyskiwania po awarii?
Miernik RTO określa z góry docelowe oczekiwania dla zespołu IT, ponieważ określa próg szybkości przywracania systemu lub aplikacji po przestoju i ponownego włączenia systemu. Po zdefiniowaniu tej miary w kategoriach ilości „czasu rzeczywistego” potrzebnego do przywrócenia systemu, można zaplanować strategię odzyskiwania, aby usługa ponownie działała. Aby obliczyć RTO, należy wziąć pod uwagę straty związane z przerwą w docelowym czasie przywracania planu ciągłości działania (BCP). Uwzględnij również analizę wpływu, która wyjaśnia krótko- lub długoterminowe skutki przerwy w świadczeniu usług. Obejmuje to zagrożenia, utracone przychody, wydatki, aplikacje skierowane do klientów, aplikacje o znaczeniu krytycznym oraz aplikacje o mniejszym priorytecie, których dotyczy problem lub które staną się niedostępne. RTO jest bardziej zainteresowany przestojami i ograniczeniami czasowymi procesu odzyskiwania danych.
Aby wypracować RTO, możesz potrzebować wielu kategorii RTO, ponieważ niektóre awarie mogą nie wymagać długiego czasu odzyskiwania, a niektóre mogą wymagać innych rozwiązań ochrony długoterminowej. Na przykład RTO może być znacznie dłuższy w przypadku aplikacji o mniejszym znaczeniu (nieużywanych często). W oparciu o poziomy złożoności wielu działających systemów bezpieczeństwa może być konieczne ustawienie RTO zgodnie z kopiami zapasowymi o krótkim i długim odstępie czasu. Może się to zdarzyć z powodu zdarzenia ransomware lub innego incydentu masowej katastrofy.
Czynniki pierwsze, które należy wziąć pod uwagę przy obliczaniu RTO
- Równanie kosztów i korzyści dla rozwiązań odzyskiwania
- Zastosowania priorytetowe poszczególnych systemów i danych
- Kroki, które powinien podjąć dział IT w oparciu o procesy, zautomatyzowane techniki lub technologie przywracania infrastruktury IT
- Koszt przestojów i łagodzenia
- Złożoność procedury odzyskiwania
Interwały próbkowania RTO
Osiągnięcie prawie zerowego RTO jest kosztowne dla większości przedsiębiorstw IT, ale jest możliwe do osiągnięcia, jeśli priorytetowo traktuje się aplikacje i dane. W przypadku aplikacji o mniejszym znaczeniu biznesowym zegar RTO może zużywać dłuższe czasy obiektywne niż zwykle. Plany RTO bliskie zeru dla aplikacji o znaczeniu krytycznym mogą wymagać rozważenia możliwości natychmiastowego przełączenia awaryjnego.
W zależności od powagi awarii można ustawić osiągalny docelowy czas RTO. Jednak czas przywrócenia RTO zależy również od ograniczeń organizacji IT. Na przykład, jeśli przywrócenie wszystkich funkcji i operacji IT zajmuje 3 godziny, RTO musi wynosić co najmniej 3 godziny.
Note: Z punktu widzenia odtwarzania po awarii (DR), zegar RTO rozpoczyna się w momencie rozpoczęcia procesu odzyskiwania.
Podczas obliczania RTO (docelowy czas odzyskiwania) dla jednostek biznesowych należy wziąć pod uwagę następujące przykładowe interwały:
1 godzin
Ten interwał dotyczy nadmiarowego tworzenia kopii zapasowych danych na zewnętrznych dyskach twardych.
Dni 5
W takim przypadku najbardziej opłacalnym rozwiązaniem byłoby tworzenie kopii zapasowych danych przy użyciu dysku kompaktowego, taśmy lub zewnętrznej pamięci dyskowej.
Osiągnij RTO, sposób Zmanda
Cel czasu odzyskiwania (RTO) i Cel punktu odzyskiwania (RPO) są niezwykle ważnymi celami i stanowią podstawę planu naprawy. Jak określasz szereg kroków praktycznych celów odzyskiwania? Tutaj możemy pomóc!
Dzięki planowi DRaaS firmy Zmanda i niestandardowym umowom dotyczącym poziomu usług, niezależnie od wielkości Twojej firmy, możemy pomóc Ci skrócić czas przestojów i uniknąć uciążliwości związanych z przestojami w zależności od Twoich potrzeb biznesowych. Oprócz hybrydowych kopii zapasowych wspierających przejście i osiągających stosunkowo szybsze RTO, nasze rozwiązanie dla przedsiębiorstw łączy Amazon Glacier z 20-krotnie niższym kosztem długoterminowej archiwizacji danych, co zapewnia wysoką dostępność i ciągłość biznesową.
Nasze rozwiązanie do tworzenia kopii zapasowych dla przedsiębiorstw łączy tworzenie kopii zapasowych, odzyskiwanie po awarii i długoterminowe archiwizowanie pamięci masowej, specjalnie dostosowane do potrzeb klientów. Zapewnia to bezpieczeństwo, niezawodność, skalowalność i dostępność przy jednoczesnym odzyskiwaniu środowiska nawet w przypadku wystąpienia całkowitej awarii serwera.
Przekonaj się sam! Zacznijmy od Przetestuj za darmo aby opracować strategię tworzenia kopii zapasowych danych lub zażądać próbny. Masz pytania? Skontaktuj się z nami tutaj.
