technologia

Disaster Recovery: rola RTO i RPO w procesie planowania

W sytuacji poważnej awarii często okazuje się, że przywrócenie normalnego funkcjonowania firmy bez zapasowego środowiska IT jest problematyczne i kosztowne. Dlatego też niezbędny są procedury i zasoby pozwalające uruchomić Disaster Recovery Plan. O jego skuteczności decydują wskaźniki RTO i RPO. Z tego tekstu dowiesz się, w jaki sposób zminimalizować skutki awarii bez nadszarpnięcia firmowego budżetu.

Poważne awarie infrastruktury IT (szczególnie w środowisku chmurowym) zdarzają się rzadko, ale mogą być bardzo dotkliwe w skutkach. Żadna firma nie może sobie dzisiaj pozwolić na utratę danych czy dłuższy przestój, spowodowany unieruchomieniem aplikacji. Dla firm świadczących usługi online i e-commerce’ów może to oznaczać poważną stratę finansową, a dla instytucji zaufania publicznego, jak banki, nawet konsekwencje prawne. Co ciekawe, zdecydowana większość e-sklepów nie jest w stanie oszacować, ile kosztuje godzina przestoju ich biznesu. Te, które potrafią to zrobić, szacują, że tracą nawet do 20 tysięcy złotych na godzinę. Tak wynika z Raportu Grupy K2 „Technologie i marketing w e-commerce – wyzwania i trendy 2021”.

Disaster Recovery Plan czyli plan B

O ile firmy mają już coraz większą świadomość wagi backupu i regularnego wykonywania kopii zapasowych danych, o tyle kwestia samego odtworzenia lub uruchomienia nowej infrastruktury bywa zaniedbywana. W razie awarii sama kopia danych to za mało, aby przywrócić działanie systemu. Niezbędne jest gotowe do przejęcia ruchu środowisko, na którym można niezwłocznie odtworzyć działanie systemu.

Dlatego też każda organizacja powinna zadbać w ramach Planu ciągłości biznesowej (Business Continuity Plan) o Plan odtworzenia po awarii (Disaster Recovery Plan). Disaster Recovery Plan obejmuje procedury i procesy, które należy uruchomić, aby przywrócić podstawowe funkcjonowanie firmy po katastrofie (klęsce żywiołowej, zamachu terrorystycznym czy cyberataku).

Czytaj również: Dlaczego wozimy ze sobą koło zapasowe, a nie korzystamy z Disaster Recovery Center? >>

Różne modele Disaster Recovery Center

Ważnym elementem DRP jest zapewnienie zapasowego centrum przetwarzania danych, czyli Disaster Recovery Center. W razie awarii przejmie ono rolę podstawowego ośrodka i pozwoli Ci szybko uruchomić aplikacje. Kopię zapasową infrastruktury lokalnej możesz przechowywać np. w chmurze (tworząc środowisko hybrydowe). Jeśli korzystasz już z chmury, DRC możesz utworzyć w innej chmurze (multicloud) lub w innym regionie bądź subregionie dostawcy usług. Ważne, aby był to niezależny sprzętowo, a często również lokalizacyjnie ośrodek.

Jaki model DRC wybrać? Powinien być on dostosowany do typu działalności i złożoności systemów, Twoich potrzeb biznesowych oraz możliwości finansowych. W wyborze najlepszego rozwiązania niezbędna jest analiza kluczowych wskaźników, jakimi są RTO i RPO. To one pozwalają określić wymagania organizacji i oszacować na jakie straty może sobie ona pozwolić.

Zapraszamy na bezpłatne konsultacje - otrzymasz naszą rekomendację dotyczącą najlepszego dla Ciebie rozwiązania oraz jego wycenę.

Czytaj również: Jak zapewnić bezpieczeństwo danych w chmurze dzięki regionom i subregionom>>

RTO i RPO a skuteczność Disaster Recovery

Recovery Point Objective (RPO) określa częstotliwość, z jaką powinna być wykonywana kopia zapasowa danych. W zależności od rodzaju działalności biznesowej, może okazać się, że taki backup wystarczy wykonać raz na kilka dni. Dla dużych biznesów internetowych, np. procesujących transakcje finansowe online, utrata danych z okresu powyżej 1 sekundy nie będzie jednak akceptowalna. Przygotowując Disaster Recovery Plan, należy przeanalizować wszystkie procesy biznesowe, określić te krytyczne i do nich dostosować parametr RPO, aby utrata newralgicznych danych była jak najmniejsza.

Jeśli wykonujesz backup raz na dobę, stracisz najwyżej dane z 24 godzin. Czy to jest strata akceptowalna dla Twojego biznesu? Zapewne dla niektórych aplikacji niemających wpływu np. na procesy produkcyjne tak, ale już dla transakcji online w e-sklepie będzie ona zbyt duża. Dlatego też RPO powinno być ustalane w zależności od priorytetu aplikacji.

Z kolei Recovery Time Objective (RTO) określa, ile czasu zajmie przywrócenie stanu systemu sprzed awarii. W ustalaniu RTO istotne jest to, przez jaki długi czas organizacja może sobie pozwolić na wyłączenie aplikacji tak, aby nie powodowało to poważnych strat. Znów, jak w przypadku RPO, są aplikacje których unieruchomienie nawet na kilka dni nie będzie stanowiło problemu oraz takie, które powinny być przywrócone w ciągu maksymalnie kilku minut. Ponownie głównym zadaniem jest priorytetyzacja aplikacji i ustalanie potencjalnej, akceptowalnej straty. A następnie oszacowanie czasu, jaki jest potrzebny, aby przywrócić pełną dostępność aplikacji.

Podsumowując, RPO oznacza wolumen danych, który może zostać utracony podczas przestoju. RTO określa czas, jaki może upłynąć, zanim zostanie przywrócona normalna działalność biznesowa po awarii. Oba parametry są ważnym elementem umowy SLA, czyli umowy o gwarantowanym poziomie usług.

Wysoka dostępność w niskiej cenie

Uzyskanie RTO i RPO wynoszącego zero dla wszystkich aplikacji jest niemożliwe, choćby ze względu na czas potrzebny, aby dokonać kopii zapasowej danych i uruchomienia procedur naprawczych. Celem organizacji powinno być dążenie do jak najniższej wartości tych wskaźników dla newralgicznych aplikacji. Trzeba pamiętać, że im niższe RPO i RTO tym wyższe koszty rozwiązania. Ustalenie optymalnych parametrów dla poszczególnych aplikacji jest najczęściej kompromisem między potrzebami biznesu, a opłacalnością.

Sposobem, aby osiągnąć niemal nieprzerwaną, bezstratną pracę aplikacji jest zaprojektowanie awaryjnego środowiska w chmurze, wykorzystującego ciągłą replikację danych z serwerów produkcyjnych na zapasowe. W takim modelu RPO i RTO będą bardzo bliskie zeru a przywrócenie aplikacji do działania będzie niemal natychmiastowe.

W przypadku, gdy możemy sobie pozwolić na dłuższe czasy RPO i RTO dobrym rozwiązaniem jest usługa backupu w chmurze (Backup as a Service, w skrócie BaaS), która sprawia, że płacimy za wykonywanie kopii zapasowych danych zewnętrznemu dostawcy. Pozwala to uniknąć kosztów zakupu sprzętu i utrzymania infrastruktury, która koszty będzie generować tylko podczas trwania Disaster Recovery Plan. Dodatkowo dzięki wykorzystaniu technologii backupu przyrostowego kopiowane są jedynie te pliki, które uległy zmianie od momentu wykonania ostatniego pełnego backupu. To pozwala ograniczyć ilość wykorzystywanych zasobów dyskowych.

Czytaj również: Bezpieczny backup danych w chmurze>>

Jednak sam backup danych to jednak za mało, aby przywrócić funkcjonowanie firmy, jeśli awarii uległa infrastruktura IT. Niezbędnym elementem jest zapasowe centrum danych, które może być dodatkowym obciążeniem finansowym dla firmy.

Jednym ze sposobów, aby obniżyć koszty DRC, jest skorzystanie z usługi Disaster Recovery as a Service (DRaaS). W przeciwieństwie do BaaS, zamiast tworzyć własny zespół specjalizujący się w odtwarzaniu awaryjnym, można ten proces outsource’ować. Korzystając z usługi DRaaS u dostawcy chmurowego jak Oktawave, masz pewność, że zespół specjalistów nie tylko zaprojektuje optymalne środowisko, ale też zajmie się jego konfiguracją i zarządzaniem. Koszty DRC w chmurze w porównaniu do podstawowego ośrodka przetwarzania są niewielkie. Za zapasowy ośrodek płacimy dopiero wtedy, gdy faktycznie korzystamy z jego zasobów, czyli w razie awarii.

Posiadanie planu B (odpowiednich procedur, specjalistów i zasobów w zasięgu ręki) pozwala na prowadzenie biznesu bez obaw o jego stabilność. A dzięki funkcjonalności chmury obliczeniowej pewność i koszty tego spokoju nie są wygórowane. Zarówno BaaS jak i DRaaS pozwalają zminimalizować koszty zabezpieczania i odzyskiwania danych oraz całych systemów po katastrofie.

Jeśli szukasz partnera, który pomoże Ci w uruchomieniu, konfiguracji i zarządzaniu DRC, skontaktuj się z Oktawave. Uruchom środowisko chmurowe w dowolnym regionie Oktawave, a otrzymasz Disaster Recovery Center w innym regionie. Dowiedz się więcej o promocji >>