Czym jest RTO i RPO w odzyskiwaniu danych po awarii?
W przypadku odzyskiwania danych po awarii liczby te określają, jak długo organizacja doświadcza przestoju i jak wiele danych może zostać utraconych. W tym ważnym kontekście, czym jest „dobry” cel punktu odzyskiwania lub cel czasu odzyskiwania? Odpowiedź nie jest jednoznaczna. Dobry standardowy RPO/RTO zależy od rodzaju katastrofy, a także od maksymalnego tolerowanego okresu zakłóceń.
Po pierwsze, ważne jest zdefiniowanie potencjalnego zestawu katastrof, przed którymi chcesz chronić swoją organizację. Niektóre katastrofy wymagające odzyskiwania danych i tworzenia kopii zapasowych obejmują:
- Utrata danych: Może to być tak proste, jak usunięcie przez kogoś folderu, lub tak złożone, jak w przypadku oprogramowania ransomware lub zainfekowanej bazy danych.
- Utrata aplikacji: Dotyczy to sytuacji, gdy zmiany w zabezpieczeniach, aktualizacja lub konfiguracja systemu negatywnie wpływają na usługi.
- Utrata systemu: Obejmuje to awarię sprzętu lub, jeśli masz serwer wirtualny, awarię systemu operacyjnego.
- Utrata lokalizacji firmy: W tym przypadku, katastrofa może obejmować awarię elektryczną, pożar, powódź, a nawet wyciek chemiczny na zewnątrz budynku. Obiekty biznesowe wymagają odzysku do alternatywnej lokalizacji.
- Utrata operacji: Jest to całkowite zatrzymanie operacji biznesowych – tj. najgorszy scenariusz.
Każdy z tych potencjalnych scenariuszy ilustruje, jak ważne jest uwzględnienie danych, systemów, aplikacji i fizycznej lokalizacji w strategii odzyskiwania danych po awarii. Czynniki te odgrywają rolę w wartościach RTO i RPO. Po zdefiniowaniu konkretnych scenariuszy awarii, przed którymi chcemy się zabezpieczyć, można określić priorytety scenariuszy, na których zapobieganiu najbardziej zależy klientowi, a następnie wdrożyć funkcje ochrony danych odpowiadające jego wymaganiom w zakresie RTO i RPO.
Trzecia liczba ma wpływ na strategię RTO/RPO: maksymalny tolerowany okres zakłóceń (MTPD). Oznacza on, jak długo klient jest w stanie zarządzać kryzysowo przerwą w działaniu systemu i różni się dla każdej aplikacji i usługi, którą zarządzasz. Czynniki, które wpływają na tę wartość, obejmują koszty materialne, takie jak płace pracowników, spadek sprzedaży, spadek cen akcji i wydatki związane z usuwaniem skutków awarii, a także czynniki niematerialne, takie jak ryzyko utraty reputacji. Ważne jest, aby omówić MTPD z klientem, a następnie zastosować tę liczbę do strategii redukcji RTO/RPO.
Na przykład, dla danej aplikacji maksymalny okres tolerancji klienta może wynosić dwie godziny. Oznacza to, że Twój cel dotyczący czasu odzyskiwania danych musi być mniejszy niż dwie godziny, a kopie zapasowe danych muszą być tworzone rzadziej niż co dwie godziny, aby spełnić idealne RPO. Daje to wytyczne potrzebne do stworzenia fizycznego i wirtualnego systemu, który spełni potrzeby klienta w przypadku katastrofy.
Jeśli Twój klient nie jest pewien, jaki jest jego maksymalny tolerowany okres zakłóceń, istnieje kilka kluczowych pytań, które mogą pomóc mu w ustaleniu lepszych oczekiwań. Zadaj poniższe pytania, aby zrozumieć RTO i RPO klienta na bardziej szczegółowym poziomie.
- Jak często zmienia się ten typ danych?
- Ile kosztuje każda minuta przestoju tej usługi, w postaci utraconych przychodów lub utraconej produktywności?
- Czy w razie potrzeby mógłbyś prowadzić interesy przy użyciu ołówka i papieru, gdy ta usługa jest wyłączona?
- Jeśli doświadczasz przestojów, jak wpływają one na Twoich klientów?
Poruszanie się po tych pytaniach z klientem może pomóc w ustaleniu, co i w jaki sposób należy archiwizować, aby zminimalizować ryzyko w przypadku awarii.
Co to jest RTO i RPO w SQL Server?
Serwer SQL to specyficzny dla firmy Microsoft system zarządzania relacyjną bazą danych, który przechowuje i pobiera dane zgodnie z żądaniami innych aplikacji. Serwer umożliwia użytkownikom skonfigurowanie automatycznych kopii zapasowych dziennika, które są przywracane z serwera rezerwowego. Dzięki tej wysyłce dziennika użytkownicy mogą odzyskać dość aktualną kopię bazy danych – w zależności od wymagań RTO i RPO tego procesu. Wymagania RTO i RPO są ustalane przez użytkowników w zależności od ich potrzeb, budżetu i ograniczeń technologicznych sieci.
Jednakże RTO i RPO SQL Server nie zawsze są proste. W wielu przypadkach proces ten nie jest tak szybki, jak klient mógłby sobie wyobrazić. Klient może mieć na myśli idealne RPO, ale wolne prędkości sieci lub nieprawidłowo skonfigurowana kopia zapasowa mogą spowolnić ten proces. Ponadto, przywracanie kopii zapasowej logów w ten sposób może wymagać przeniesienia dużej ilości danych, a proces ten może łatwo przekroczyć ustalony akceptowalny RTO.