Jak budować i mierzyć odporność cyfrową biznesu? Rola Disaster Recovery (DR) i Business Continuity Planning (BCP)
W SKRÓCIE
W związku z rosnącą liczbą cyberzagrożeń w Polsce, dojrzała odporność cyfrowa staje się kluczowym elementem strategii każdego przedsiębiorstwa. Budowa skutecznej ochrony wymaga precyzyjnego rozróżnienia oraz integracji dwóch komplementarnych obszarów: Business Continuity Planning (BCP), czyli całościowego planu ciągłości działania organizacji w warunkach kryzysowych, oraz Disaster Recovery (DR), stanowiącego jego technologiczny fundament odpowiedzialny za awaryjne odtwarzanie systemów IT i baz danych. Efektywność tych działań mierzy się za pomocą wskaźników czasu przestoju (RTO, MTPD) oraz dopuszczalnej utraty danych (RPO, MTDL). Nowoczesną odpowiedzią na te wyzwania jest chmura publiczna i podejście hybrydowe, które eliminują potrzebę utrzymywania kosztownej, bezczynnej infrastruktury i automatyzują procesy odzyskiwania danych. Należy jednak pamiętać, że migracja do chmury podlega modelowi współdzielonej odpowiedzialności, w którym ochrona samych danych i aplikacji przed atakami typu *ransomware* zawsze pozostaje po stronie użytkownika, nie dostawcy.
Wyobraź sobie sytuację, w której o 4:27 nad ranem budzi Cię telefon z informacją, że wszystkie dane Twojej firmy zniknęły. Faktury, bazy klientów, projekty, cała historia operacyjna – zablokowane lub bezpowrotnie usunięte. Czy Twój biznes jest na to gotowy?
W dzisiejszych realiach rynkowych i przy stale rosnącej liczbie cyberataków ciągłość działania i bezkompromisowa ochrona danych to absolutne fundamenty bezpieczeństwa. Ryzyko przestaje być jedynie teoretyczne – według raportu CERT, w 2025 roku liczba zarejestrowanych incydentów cyberbezpieczeństwa wzrosła aż o 152% w stosunku do poprzedniego, co oznacza, że każdego dnia dochodziło do niemal 2 tysięcy realnych incydentów. Cena ewentualnego przestoju wynikającego ze skutecznego ataku także bywa dla biznesu dotkliwa. Według danych Splunk Inc. oraz Oxford Economics, awarie i ataki powodują średnio 9-procentowy spadek cen akcji spółek, a powrót do wyceny sprzed kryzysu trwa statystycznie aż 79 dni. Do tego dochodzą bezpośrednie straty finansowe i utrata klientów.
Przedsiębiorstwa stoją dziś przed kluczowym wyzwaniem: jak skutecznie zabezpieczyć się przed scenariuszami, które często bywają nieuniknione? Kluczowa jest dojrzała odporność cyfrowa (ang. cyber resilience), do której zbudowania niezbędna jest wiedza na temat Business Continuity Planning (BCP) i Disaster Recovery (DR). Te komplementarne strategie zarządzania kryzysowego pozwalają na skuteczne zarządzanie ciągłością działania oraz szacowanie ryzyka operacyjnego w organizacji.
Po przeczytaniu tego artykułu będziesz wiedzieć:
- czym są oraz jaka jest różnica między Disaster Recovery (DR) a Business Continuity Planning (BCP),
- jakie wyróżniamy filary technologiczne planowania ciągłości działania (BCP),
- jakie kluczowe metryki bezpieczeństwa warto znać i rozumieć,
- jak chmura publiczna i podejście hybrydowe redefiniują współczesne standardy ochrony danych.
Jaka jest różnica między Business Continuity Planning (BCP) a Disaster Recovery (DR)?
Pojęcia Disaster Recovery (DR) i Business Continuity Planning (BCP) często stosowane są zamiennie. Tymczasem Disaster Recovery jest technologicznym sercem znacznie większego organizmu, jakim jest Business Continuity Planning.
Czym jest Disaster Recovery (DR)?
Disaster Recovery (DR), czyli odtwarzanie awaryjne, to zestaw ściśle określonych procedur, technologii i polityk, które pozwalają na przywracanie systemów IT oraz kluczowej infrastruktury i baz danych po wystąpieniu sytuacji kryzysowej (np. awarii zasilania, cyberataku ransomware czy klęski żywiołowej). DR koncentruje się na aspekcie technicznym i technologicznym. Jego głównym celem jest minimalizacja przestojów oraz ochrona przed utratą krytycznych danych biznesowych poprzez wykorzystanie np. zapasowych centrów danych.
Czym jest Business Continuity Planning (BCP)?
Business Continuity Planning (BCP) – czyli planowanie ciągłości działania, to z kolei bardziej kompleksowa strategia biznesowa. Podczas gdy DR skupia się na tym, jak uruchomić systemy IT, BCP odpowiada na pytanie, jak firma ma funkcjonować w trakcie kryzysu i tuż po nim. Definicja BCP obejmuje nie tylko infrastrukturę, ale także ludzi, procesy, komunikację, fizyczne lokalizacje oraz łańcuchy dostaw. Na przykład, jeśli Twoje serwery działają, ale pracownicy nie mają skąd pracować lub jak się ze sobą komunikować, plan DR zadziałał, ale BCP zawiodło.
Filary technologiczne planowania ciągłości działania (BCP)
Aby strategia BCP była skuteczna, powinna zakładać wykorzystanie kilku narzędzi jednocześnie i wymagać warstwowego podejścia, w którym każda technologia odpowiada na inny rodzaj ryzyka – od skasowania pliku, przez pożar serwerowni, aż po kary związane z niespełnieniem konkretnych wymogów prawnych. Poniżej znajdziesz kilka przykładów rozwiązań, które mogą (i powinny) ją tworzyć.
1. Kopie zapasowe (backup), czyli codzienna higiena danych
Kopia zapasowa to primeira i podstawowa linia obrony, która jest swego rodzaju „ubezpieczeniem operacyjnym” od codziennych, lokalnych problemów.
Rola w BCP
Zapewnienie możliwości odtworzenia konkretnych zasobów (plików, baz danych, maszyn wirtualnych) do stanu z przeszłości.
Główne zadania:
- Ochrona przed przypadkowym usunięciem danych (błąd ludzki)
- Ochrona przed uszkodzeniem danych (korupcja plików, błędy aplikacji)
- Zapewnienie historycznych wersji plików (np. „potrzebuję wersji budżetu sprzed tygodnia”)
Złożoność wdrożenia: niska/średnia
Nowoczesne rozwiązania typu set and forget; instalacja agentów i konfiguracja harmonogramów jest zazwyczaj prosta.
Złożoność utrzymania: średnia
Wyzwanie polega na skali – przy setkach serwerów należy monitorować, czy proces tworzenia backupu zakończył się sukcesem (ang. success rate). Problemem bywa też zarządzanie przestrzenią dyskową (retencja).
2. Disaster Recovery (DR), czyli koło ratunkowe dla biznesu
Jeśli backup to „koło zapasowe”, DR jest „zapasowym samochodem”. W strategii BCP Disaster Recovery odpowiada za przetrwanie organizacji w momencie, gdy główna siedziba lub centrum danych przestaje istnieć lub działać.
Rola w BCP
Zminimalizowanie czasu przestoju (RTO) oraz umożliwienie pracownikom i klientom korzystania z systemów, nawet gdy główna infrastruktura jest niedostępna.
Główne zadania:
- Replikacja danych i systemów do drugiej lokalizacji (lub chmury) w czasie bliskim rzeczywistemu
- Automatyzacja procesu przełączania awaryjnego (ang. failover) i uruchomienie systemów zapasowych
- Orkiestracja sieci tak, aby użytkownicy zostali automatycznie przekierowani do działającego ośrodka
Złożoność wdrożenia: wysoka
Wymaga nie tylko narzędzi (np. Zerto, Commvault, VMware Live Site Recovery aka SRM), ale przede wszystkim zaprojektowania sieci, mapowania adresów IP i zrozumienia zależności między aplikacjami.
Złożoność utrzymania: wysoka
Wymaga regularnych, bardziej lub mniej inwazyjnych testów. Każda zmiana w środowisku produkcyjnym (nowy serwer, zmiana w sieci) musi być odzwierciedlona w planie DR – inaczej system awaryjny nie zadziała.
3. Złota kopia (ang. Golden Copy/Cyber Recovery), czyli ostatni bastion ochrony
W dobie cyberataków standardowy backup i DR mogą zostać zaszyfrowane razem z danymi produkcyjnymi. Złota kopia to specjalistyczny element BCP nastawiony na budowanie odporności cyfrowej, który może – a nawet powinien – być traktowany również jako ostateczna linia obrony w scenariuszu totalnej katastrofy fizycznej (zniszczenie wszystkich ośrodków). Jest to możliwe pod warunkiem jednego kluczowego wymogu: lokalizacji.
Rola w BCP
Gwarancja, że posiadamy czystą, niezainfekowaną kopię danych, z której można odbudować środowisko po totalnym ataku ransomware. Umożliwia też odtworzenie tzw. cyfrowego dziedzictwa firmy w przypadku rozległej katastrofy lub wojny.
Główne zadania:
- Zablokowanie możliwości edycji lub usunięcia danych przez określony czas (nawet dla administratora)
- Odizolowanie kopii od sieci produkcyjnej (fizycznie lub logicznie), aby haker nie mógł się do niej dostać, a dane mogły zostać odtworzone nawet w przypadku utraty wszystkich ośrodków obliczeniowych na tymczasowych zasobach obliczeniowych lub po odtworzeniu infrastruktury
- Skanowanie bezpieczeństwa, czyli weryfikacja kopii pod kątem obecności złośliwego oprogramowania przed odzyskaniem danych
Złożoność wdrożenia: średnia/niska
Wymaga odpowiedniego sprzętu (m.in. macierze z blokadą obiektową, taśmy) lub dedykowanych usług w chmurze oraz restrykcyjnych polityk dostępu.
Złożoność utrzymania: średnia/niska
Kluczowe jest zarządzanie kluczami szyfrującymi i procesami uwierzytelniania (często wymagana jest autoryzacja wieloosobowa).
Alfabet bezpieczeństwa, czyli kluczowe metryki Disaster Recovery (DR) i Business Continuity Planning (BCP)
Aby skutecznie zaprojektować zarówno strategię BCP, jak i DR, niezbędna jest znajomość języka metryk. To właśnie one wyznaczają granicę między drobną niedogodnością a przestojem firmy. Zrozumienie poniższych terminów jest kluczowe również dla ustalenia budżetu i doboru technologii – nie da się chronić wszystkiego bez nieskończonego źródła finansowego, dlatego obowiązkowym krokiem, który należy wykonać, jest zdefiniowanie limitów.
1. RPO (Recovery Point Objective, tłum. cel punktu odzyskiwania)
RPO określa maksymalną ilość danych, jaką firma może stracić w wyniku awarii, mierzoną w czasie. W praktyce parametr ten wyznacza, jak aktualne muszą być przywrócone dane – na przykład RPO wynoszące 4 godziny oznacza, że systemy muszą zostać odtworzone ze stanu nie starszego niż sprzed 4 godzin.
Przykład: Jeśli RPO wynosi 4 godziny, a awaria nastąpiła o 12:00, system odtworzy dane aktualne na godzinę 08:00. Wszystko, co zostało wprowadzone między 08:00 a 12:00, przepada.
Warto wiedzieć: Im niższe RPO (np. bliskie zera), tym częściej musimy wykonywać backup lub replikację, co drastycznie podnosi koszty rozwiązania.
2. RTO (Recovery Time Objective, tłum. cel czasu odzyskiwania)
RTO to parametr, który określa, jak długo systemy mogą nie działać. Jest to czas liczony od momentu wystąpienia awarii do momentu przywrócenia pełnej dostępności usług dla użytkowników.
Przykład: Jeśli RTO wynosi 2 godziny, to od momentu awarii serwera zespół IT ma dokładnie 120 minut na diagnozę, naprawę, odtworzenie danych i uruchomienie aplikacji.
Warto wiedzieć: Krótsze RTO wymaga bardziej zautomatyzowanych rozwiązań (np. systemy High Availability lub Hot Site DR), które są droższe niż odtwarzanie z taśm czy zimnego backupu.
3. MTPD (Maximum Tolerable Period of Disruption, tłum. maksymalny dopuszczalny okres zakłócenia)
Często mylone z RTO, ale to absolutna granica krytyczna dla biznesu. MTPD to czas, po upływie którego skutki braku dostępności usługi stają się nieodwracalne i mogą doprowadzić do upadłości firmy lub gigantycznych strat wizerunkowych lub finansowych.
Warto wiedzieć: RTO musi być zawsze krótsze niż MTPD. Jeśli MTPD wynosi dla firmy 24 godziny przestoju, to Twoje RTO powinno wynosić np. 12-16 godzin, aby zachować margines bezpieczeństwa na nieprzewidziane problemy podczas odtwarzania, umożliwić weryfikację spójności danych i przywrócenie procesów biznesowych.
4. MTDL (Maximum Tolerable Data Loss, tłum. maksymalna dopuszczalna utrata danych)
MTDL to biznesowy odpowiednik technicznego RPO. Określa ilość lub wartość danych (np. liczba transakcji, rekordów klientów), których utrata jest „akceptowalna”, tzn. nie zaburzy w sposób krytyczny działania firmy.
Warto wiedzieć: MTDL dyktuje RPO. Jeśli biznes stwierdza, że MTDL to „maksymalnie 100 utraconych zamówień”, a w godzinach szczytu wpływa 100 zamówień na minutę, to techniczne RPO musi wynosić poniżej 1 minuty. Często w kontekście BCP używa się MTDL, aby uświadomić zarządowi, że „backup raz dziennie” (RPO = 24h) jest nieakceptowalny przy ich wymaganiach biznesowych.
Chmura publiczna jako turbodoładowanie dla BCP i DR
Wiesz już, że BCP to strategia przetrwania, a DR to bardziej koło ratunkowe. Chmura publiczna (np. AWS, Microsoft Azure, Google Cloud) zmienia sposób, w jaki te technologie są dostarczane, czyniąc niemożliwe dotąd parametry RPO i RTO osiągalnymi dla firm, które nie dysponują dużym budżetem. Poniżej znajdziesz kilka elementów, które sprawiają, że chmura publiczna deklasuje tradycyjne podejście „drugiej serwerowni”:
1. Koniec z zombie data centers
W tradycyjnym modelu on-premise, aby zapewnić niskie RTO (szybki powrót do pracy), trzeba utrzymywać drugą, niemal identyczną serwerownię, która przez 99% czasu stoi bezczynnie, zużywając prąd i licencje, czyli tzw. zombie data center.
Przewaga chmury: Postaw na model pay-as-you-go (PAYG), w którym nie musisz płacić za pełną moc obliczeniową, gdy jej nie używasz. Możesz utrzymywać tzw. pilot light, czyli minimalną, tanią infrastrukturę w chmurze, która przechowuje replikę danych, utrzymuje węzeł sieciowy i usługę katalogową. Dopiero w momencie katastrofy uruchamiasz setki serwerów, płacąc za nie tylko wtedy, gdy faktycznie ratują Twój biznes. Ważnym aspektem jest to, że dostawcy chmury są w stanie zaoferować licencje w modelu PAYG. W tradycyjnym scenariuszu sam zakup licencji sprawiał często, że klienci rezygnowali z tego typu rozwiązań.
2. Geograficzna redundancja out-of-the-box
Nie da się ukryć, że budowa własnej serwerowni zapasowej w innym mieście (nie wspominając o innym kontynencie) to bardzo skomplikowany proces pod względem logistycznym i prawnym.
Przewaga chmury: Dostawcy technologii chmurowej posiadają swoje centra danych na całym świecie. Kilkoma kliknięciami myszy możesz skonfigurować replikację danych z Warszawy do Frankfurtu, Dublina czy Singapuru. To sprawia, że BCP jest odporne na katastrofy regionalne (powodzie, trzęsienia ziemi, wojny), co w modelu tradycyjnym byłoby ekstremalnie trudne do osiągnięcia.
3. Infrastruktura jako kod (IaC), czyli nowa definicja runbooka
Tradycyjny plan odtwarzania (ang. runbook) to często obszerny dokument, który trzeba czytać i ręcznie wykonywać krok po kroku, co – szczególnie pod wpływem stresu – prowadzi do wielu błędów.
Przewaga chmury: W chmurze całą infrastrukturę (sieci, serwery, zabezpieczenia) możesz opisać kodem (np. Terraform, Bicep, CloudFormation). Odtworzenie skomplikowanego środowiska nie polega na ręcznym klikaniu, ale na uruchomieniu jednego skryptu, co znacznie skraca RTO i pozwala wyeliminować wiele błędów.
4. Testowanie bez zakłóceń
To często pomijany, ale bardzo kluczowy aspekt. W tradycyjnym IT testy DR są trudne, mogą wymagać zatrzymania produkcji lub są ryzykowne dla działających systemów, dlatego robi się je rzadko (lub wcale).
Przewaga chmury: Możesz w dowolnej chwili uruchomić kopię swojego środowiska w odizolowanej sieci w chmurze (tzw. sandbox), przeprowadzić testy odtwarzania, udowodnić audytorom, że Twoje RPO/RTO są realne i możliwe do osiągnięcia, a następnie usunąć środowisko i przestać za nie płacić.
Czy klienci chmury publicznej też potrzebują w takim razie BCP?
Tak! To jedno z najczęstszych i najbardziej niebezpiecznych nieporozumień. Korzystanie z chmury nie zwalnia z odpowiedzialności za własne dane i aplikacje. Obowiązuje tu model współdzielonej odpowiedzialności (ang. shared responsibility model), o którym pisaliśmy jakiś czas temu w artykule Odpowiedzialność dostawcy chmury - jakie modele funkcjonują na rynku?.
Podział odpowiedzialności można przedstawić następująco:
- dostawca chmury (np. Google, Azure, AWS) odpowiada za bezpieczeństwo chmury, czyli za fizyczną infrastrukturę (budynki, zasilanie, sieć),
- Ty (użytkownik chmury) odpowiadasz za bezpieczeństwo w chmurze, czyli za swoje dane, aplikacje, konfigurację sieci, zarządzanie dostępem i ochronę przed ransomware.
Awaria całej strefy dostępności lub nawet całego regionu chmury, choć rzadka, jest możliwa. Atak ransomware, który zaszyfruje Twoje maszyny wirtualne w chmurze, jest w obecnych czasach scenariuszem niezwykle realnym. Z raportu ESET wynika, że w drugiej połowie 2025 roku Polska zajęła 3. miejsce na świecie pod względem liczby ataków ransomware i 2. miejsce pod względem liczby zagrożeń rozsyłanych pocztą e-mail. Dlatego każda firma, która korzysta z chmury publicznej powinna mieć plan, który zakłada co najmniej replikację kluczowych danych i systemów do innego regionu geograficznego tego samego dostawcy. Oczywiście możliwe jest wykorzystanie innych dostawców, ale jest to scenariusz, który ze względu na swoją złożoność jest wykorzystywany stosunkowo rzadko.
Podsumowanie
Znajmość podstaw teoretycznych to jedno, ale skuteczne wdrożenie strategii Disaster Recovery i planu ciągłości działania (BCP) to zupełnie inne wyzwanie. Nie ma jednego uniwersalnego szablonu na bezpieczeństwo, dlatego zanim zdecydujesz się na konkretne narzędzia, upewnij się, że na pewno uwzględniają specyfikę Twojej organizacji i jej potrzeby. Odpowiedz sobie na pytanie, czy wystarczy Ci solidna kopia zapasowe czy niezbędne jest pełne Diaster Recovery? Gdzie kluczowe jest wdrożenie złotej kopii jako ostatecznej linii obrony przed ransomware?
Jeśli czujesz, że potrzebujesz w tym zakresie wsparcia i partnera, który przeprowadzi Cię przez cały proces – od czystej kartki po w pełni przygotowany plan awaryjny – skontaktuj się z naszymi ekspertami za pomocą poniższego formularza.
W OChK poza usługami, takimi jak Backup as a Service, Disaster Recovery Center (DRC) czy złota kopia:
- projektujemy bezpieczne landing zones, zgodne z najlepszymi praktykami bezpieczeństwa (CIS Benchmarks),
- przygotowujemy odizolowane sieci (tzw. bubble networks/sandboxy), które pozwalają na prowadzenie regularnych testów odtwarzania bez żadnego wpływu na działanie systemów produkcyjnych,
- tworzymy szczegółowe procedury przełączania (ang. failover) i powrotu (ang. failback),
- dostarczamy klientowi gotowe runbooki, czyli instrukcje, które w stresie, podczas awarii, wesprą Twój zespół w działaniu krok po kroku,
- wspólnie z klientem przeprowadzamy pierwsze testy, weryfikując założone parametry RPO i RTO w praktyce.
Jako partnerzy strategiczni globalnych dostawców (Google Cloud i Microsoft Azure) oraz twórcy własnej infrastruktury, Platformy OChK, oferujemy agnostyczne podejście – projektujemy architekturę, która wykorzystuje potencjał chmury publicznej dla systemów, które tego wymagają i równolegle wykorzystujemy własną chmurę dla danych wymagających szczególnego podejścia lub specyficznych parametrów wydajnościowych. Takie hybrydowe podejście pozwala optymalizować koszty i spełniać wymogi regulacyjne (np. DORA, NIS2), których nie da się zrealizować u jednego dostawcy.
Najważniejsze pojęcia
Business Continuity Planning (BCP)
BCP (inaczej: plan ciągłości działania) to kompleksowy, udokumentowany zbiór procedur, polityk i zasobów, mający na celu zapewnienie nieprzerwanego funkcjonowania krytycznych procesów biznesowych organizacji po wystąpieniu poważnej awarii, katastrofy lub innego zdarzenia zakłócającego (np. powodzi, ataku cybernetycznego, epidemii). Strategia BCP koncentruje się na odbudowie operacyjnej całej organizacji w ramach określonych celów czasowych i ilościowych (takich jak RTO, Recovery Time Objective i RPO, Recovery Point Objective), minimalizując w ten sposób straty finansowe i reputacyjne.
Backup (kopia zapasowa)
Backup to proces regularnego tworzenia oraz bezpiecznego przechowywania kopii oryginalnych danych cyfrowych na oddzielnym nośniku lub w dedykowanej przestrzeni chmurowej. Celem tworzenia kopii zapasowych jest umożliwienie bezstratnego odtworzenia informacji w przypadku ich przypadkowego usunięcia, uszkodzenia, zaszyfrowania przez *ransomware* lub awarii sprzętowej.
Złota kopia
Złota kopia to nienaruszalna, w pełni zweryfikowana, odizolowana i traktowana jako jedyne, absolutne źródło prawdy kopia zapasowa kluczowych danych lub konfiguracji systemowych. Jest ona przechowywana w sposób uniemożliwiający jakąkolwiek modyfikację (często w trybie WORM – Write Once, Read Many) lub w środowisku całkowicie odciętym od sieci produkcyjnej ( air-gapped ), co stanowi ostateczną linię obrony np. przed destrukcyjnymi atakami *ransomware*.
Odporność cyfrowa
Odporność cyfrowa to zdolność organizacji do ciągłego przewidywania, adaptowania się oraz szybkiego podnoszenia się po wszelkiego rodzaju zakłóceniach cyfrowych, awariach technologicznych czy cyberatakach. Wykracza poza samo reagowanie na incydenty, stanowiąc całościową strategię biznesowo-technologiczną, która pozwala na nieprzerwane świadczenie kluczowych usług nawet w warunkach kryzysowych.
Disaster Recovery (DR)
Disaster Recovery (DR) to kompleksowy zestaw strategii, procedur, narzędzi oraz zasobów infrastrukturalnych przygotowanych w celu przywrócenia działania krytycznych systemów IT i infrastruktury sieciowej po wystąpieniu poważnej katastrofy (np. pożaru serwerowni, powodzi lub masowego paraliżu cybernetycznego). DR skupia się na aspekcie technicznym i technologicznym w ramach szerszego planu ciągłości działania (BCP).
Maximum Tolerable Period of Disruption (MTPD)
MTPD to maksymalny okres, przez jaki organizacja jest w stanie tolerować całkowitą niedostępność lub poważne zakłócenie danej usługi biznesowej bądź systemu, zanim straty staną się nieodwracalne i zagrożą dalszemu istnieniu firmy. Jest to graniczny parametr biznesowy, który narzuca ramy dla projektowania technicznych wskaźników odzyskiwania (RTO musi być mniejsze niż MTPD).
Maximum Tolerable Data Loss (MTDL)
MTDL to zdefiniowany przez biznes, maksymalny dopuszczalny wolumen lub wiek danych (mierzony w czasie), których utrata w wyniku awarii nie doprowadzi do trwałego paraliżu operacyjnego lub finansowego organizacji. Podobnie jak w przypadku relacji czasu, MTDL wyznacza maksymalną dopuszczalną granicę dla technicznego parametru RPO.
RPO (Recovery Point Objective)
RPO to techniczny wskaźnik określający maksymalny wiek danych, jakie organizacja może utracić w wyniku awarii, mierzony wstecz od momentu wystąpienia incydentu do czasu wykonania ostatniej skutecznej kopii zapasowej. Przykładowo, RPO wynoszące 4 godziny oznacza, że systemy muszą być archiwizowane co najmniej co 4 godziny, a biznes akceptuje utratę owoców pracy z maksymalnie takiego okresu.
RTO (Recovery Time Objective)
RTO to techniczny wskaźnik określający maksymalny dopuszczalny czas, jaki może upłynąć od momentu wystąpienia awarii lub katastrofy do pełnego przywrócenia sprawności operacyjnej danego systemu IT lub usługi. Jeśli RTO wynosi 2 godziny, oznacza to, że zespół inżynierów i infrastruktura DR muszą uruchomić środowisko produkcyjne w czasie nie przekraczającym 120 minut od zgłoszenia incydentu.
Zombie data center
Zombie data center to potoczne określenie infrastruktury serwerowej lub całego centrum danych, w którym znaczna część zasobów sprzętowych (procesory, pamięć RAM, dyski) stale pobiera prąd i generuje koszty utrzymania, mimo że nie wykonuje żadnych użytecznych operacji ani nie procesuje realnego ruchu biznesowego. Identyfikacja i eliminacja takich "serwerów-zombie" jest kluczowym elementem optymalizacji kosztów IT oraz migracji do chmury.
