Dlaczego Disaster Recovery w chmurze nie jest „z automatu” rozwiązane
Wysoka dostępność kontra Disaster Recovery – dwa różne światy
Usługi chmurowe same z siebie zapewniają sporą odporność na awarie infrastruktury. Dostawcy reklamują wysoki uptime, wbudowaną redundancję, automatyczne skalowanie. Na fakturze często pojawia się gwarantowane SLA, ale nie ma tam gotowego planu Disaster Recovery. To zasadnicza różnica: wysoka dostępność (HA) utrzymuje usługę w ruchu przy typowych awariach, natomiast Disaster Recovery (DR) pozwala odtworzyć środowisko po zdarzeniu katastroficznym.
Innymi słowy, HA ma minimalizować krótkotrwałe przerwy w działaniu aplikacji (awaria jednego serwera, chwilowe problemy sieciowe), a DR ma umożliwić powrót do działania po sytuacjach, gdy przestaje działać cała strefa, region lub zostają utracone dane. W chmurze HA zwykle kupuje się „po drodze” – poprzez load balancer, auto‑scaling czy multi‑AZ. Natomiast strategia DR wymaga osobnych decyzji: wyboru regionów zapasowych, sposobów replikacji danych, scenariuszy przełączeń i procedur odtworzeniowych.
W efekcie wiele firm błędnie zakłada, że jeśli aplikacja działa w chmurze i korzysta z kilku stref dostępności, to problem Disaster Recovery „rozwiązał się sam”. Tak nie jest. Katastrofa, którą adresuje plan DR, to zdarzenie przekraczające domyślne mechanizmy HA – i trzeba je osobno zdefiniować.
Model shared responsibility: kto jest za co odpowiedzialny
Dostawcy chmury jasno komunikują model shared responsibility. Odpowiadają za fizyczne centra danych, zasilanie, chłodzenie, sprzęt, a także za podstawowy poziom bezpieczeństwa usług zarządzanych. Natomiast klient odpowiada za to, co konfiguruje i wdraża w chmurze: strukturę sieci, konta użytkowników, konfigurację usług, aplikacje i dane.
W kontekście Disaster Recovery oznacza to, że:
dostawca zapewnia, że jego regiony i strefy są izolowane i redundantne technicznie,
ale to zespół IT definiuje, czy i jak dane są kopiowane do innego regionu,
dostawca może udostępniać funkcje backupu i replikacji,
ale to klient musi je włączyć, skonfigurować i monitorować,
dostawca utrzymuje platformę,
ale klient projektuje architekturę DR dla swoich systemów.
W praktyce granica odpowiedzialności często zaciera się w świadomości menedżerów. Po incydencie łatwo pojawia się pytanie: „Przecież jesteśmy w chmurze, jak to możliwe, że nie mamy kopii?”. Odpowiedź zwykle brzmi: „Mechanizmy były dostępne, ale nie zostały wykorzystane zgodnie z oczekiwaniami biznesu”.
Typowe scenariusze katastroficzne w środowisku chmurowym
W chmurze znacząca część zdarzeń katastroficznych wynika z błędów konfiguracji i procesów, a nie tylko z fizycznych awarii. Realne scenariusze to między innymi:
Awaria regionu lub poważny incydent w nim – rzadkie, ale możliwe. Skutkiem jest niedostępność wielu usług w danej lokalizacji. Usługi skonfigurowane wyłącznie w jednym regionie mogą przestać działać na wiele godzin.
Błąd konfiguracji lub IaC – pojedynczy błąd w skrypcie Terraform lub CloudFormation może usunąć działające zasoby lub nadpisać konfigurację produkcyjną. Bez odpowiedniego wersjonowania i procedur rollbacku, odtworzenie środowiska jest czasochłonne.
Ransomware i ataki na dane – złośliwe oprogramowanie lub przejęte konto administracyjne może zaszyfrować dane w usługach chmurowych, usunąć backupy lub zmienić uprawnienia, uniemożliwiając szybkie odtworzenie.
Masowe usunięcie danych przez człowieka – błędne polecenie, skrypt „sprzątający” albo źle przygotowane narzędzie migracyjne potrafią w kilka minut usunąć lub nadpisać kluczowe dane.
Te scenariusze nie są egzotyką. Część z nich pojawia się w raportach branżowych co roku. Pytanie nie brzmi „czy” się zdarzą, ale jak bardzo organizacja będzie na nie przygotowana.
Jakie pytania padają z ust zarządu po incydencie
Po poważnej awarii lub utracie danych rozmowa przestaje być techniczna. Zarząd chce prostych i konkretnych odpowiedzi:
„Na jak długo utraciliśmy dane?” – to wprost pytanie o osiągnięty RPO.
„Ile czasu zajmie powrót do normalnej pracy?” – to pytanie o rzeczywisty RTO.
„Które systemy wrócą jako pierwsze?” – tu pojawia się kwestia priorytetów i sekwencji odtwarzania.
„Jaki jest wpływ finansowy i wizerunkowy tej awarii?” – szacunek kosztów niedostępności i utraty danych.
„Czy dało się tego uniknąć?” – analiza luk w dotychczasowym planie DR.
Bez spisanego, przetestowanego planu Disaster Recovery odpowiedzi są zwykle rozmyte. Zespół IT reaguje ad hoc, a komunikacja z biznesem jest pełna niepewności. Odpowiednio zaprojektowany i regularnie aktualizowany plan DR w chmurze sprawia, że te pytania można pokryć konkretnymi scenariuszami, czasami i kosztami.
Źródło: Pexels | Autor: Алесь Усцінаў
Kluczowe pojęcia: RPO, RTO, RCO, RLO i inne parametry, które trzeba nazwać
RPO i RTO – cele, które rozumie biznes
RPO (Recovery Point Objective) określa, ile danych można stracić w wyniku awarii, mierzone w czasie. Przykładowo: RPO = 15 minut oznacza, że akceptowalna jest utrata danych powstałych w ciągu ostatniego kwadransa. Dla firm księgowych może to być nieakceptowalne, natomiast dla systemu wewnętrznych raportów – w zupełności wystarczające.
RTO (Recovery Time Objective) określa, jak szybko system ma wrócić do działania po incydencie. Jeśli RTO = 2 godziny, oznacza to, że od momentu decyzji o przejściu do scenariusza DR do przywrócenia pełnej funkcjonalności nie powinno minąć więcej niż 120 minut.
Ważne jest, że RPO i RTO to nie są liczby „wymyślone” przez administratorów. To cele biznesowe, które muszą wynikać z analizy wpływu przestojów na finanse, klientów i procesy. Dopiero potem zespół techniczny ocenia, jakimi środkami i za jaką cenę da się takie cele osiągnąć w chmurze.
Dodatkowe parametry: RCO i RLO – ile mocy i na jakim poziomie
W zaawansowanych planach Disaster Recovery w chmurze pojawiają się także inne wskaźniki. Dwa przydatne z nich to:
RCO (Recovery Capacity Objective) – oczekiwana pojemność i moc środowiska po odtworzeniu. Chodzi o to, czy środowisko DR ma zapewnić 100% normalnej wydajności, czy np. 60% (z ograniczeniami). Ma to znaczący wpływ na koszty: pełne odtworzenie mocy w modelu active‑active jest dużo droższe niż utrzymywanie minimalnego środowiska w modelu pilot light.
RLO (Recovery Level Objective) – określa, na jakim poziomie odtwarzamy usługę. Czy przywracamy całe środowisko (wiele aplikacji wraz z integracjami), czy pojedyncze mikrousługi, czy tylko dane. RLO porządkuje zakres planu DR i zapobiega „niedomówieniom”, gdy część systemów jest przygotowana do odtworzenia, a część pozostaje poza planem.
Przekład RPO/RTO na realne scenariusze działania
Ustalanie RPO i RTO „na sucho” prowadzi często do deklaracji typu: „RPO = 0, RTO = 0, bo system jest krytyczny”. Technicznie to nierealne albo bardzo kosztowne. Dlatego warto z biznesem przejść przez konkretne scenariusze:
Utrata danych z ostatnich 30 minut – co dzieje się z zamówieniami, transakcjami, zgłoszeniami klientów? Czy da się je odtworzyć z innych źródeł (maile, potwierdzenia bankowe)?
Utrata danych z ostatnich 24 godzin – czy oznacza to powtórne wprowadzanie dokumentów? Czy grożą kary umowne lub regulacyjne?
Brak systemu przez 1 godzinę vs. 8 godzin – czy mamy alternatywne kanały obsługi (telefon, inne aplikacje)? Jak wpływa to na sprzedaż i obsługę klienta?
Odpowiedzi na takie pytania pozwalają zderzyć oczekiwania z rzeczywistością. Jeśli okazuje się, że utrata 5 minut danych jest już krytyczna, oznacza to konieczność agresywnej replikacji lub architektury active‑active. Jeśli natomiast system ma charakter raportowy, RPO = 24 godziny i RTO = 12 godzin mogą być zupełnie akceptowalne.
Rozmowa z biznesem o krytyczności systemów
Rozmowa o RPO i RTO z biznesem jest prostsza, gdy nie zaczyna się od protokołów replikacji, a od konsekwencji przestoju. Kluczowe pytania dla właścicieli procesów to:
„Które procesy nie mogą się zatrzymać nawet na godzinę?”
„Które systemy mogą być niedostępne kilka godzin lub dni, bez ryzyka dla ciągłości działania firmy?”
„Czy istnieją procedury manualne, które tymczasowo zastąpią system?”
„Jakie są konsekwencje prawne dłuższej niedostępności (np. systemy raportowania do regulatorów)?”
Na tej podstawie można przypisać klasę krytyczności i dobrać docelowe parametry RPO/RTO. Technologia chmurowa jest wtedy środkiem do realizacji jasno zdefiniowanych potrzeb, a nie odwrotnie.
Źródło: Pexels | Autor: Diego Girón
Identyfikacja systemów krytycznych i analiza ryzyka – od katalogu usług do macierzy priorytetów
Inwentaryzacja: co faktycznie działa w chmurze
Solidny plan Disaster Recovery w chmurze zaczyna się od rzetelnej inwentaryzacji. W wielu organizacjach istnieją systemy „sieroty”, mikroserwisy uruchomione eksperymentalnie albo środowiska pozostawione po projektach pilotażowych. Brak ich uwzględnienia w planie DR może skutkować niespodziankami podczas incydentu.
Przydatna jest prosta checklista inwentaryzacyjna:
lista aplikacji uruchomionych w chmurze (produkcyjnych i kluczowych testowych),
powiązane bazy danych, magazyny obiektów, kolejki, cache,
integracje między systemami (API, strumienie danych, ETL),
komponenty sieciowe: VPC/VNet, VPN, połączenia z on‑premise, DNS, WAF,
usługi zarządzane używane krytycznie (np. zarządzane bazy, systemy tożsamości, usługi kolejkowania),
zależności od usług zewnętrznych: systemy płatności, dostawcy danych, SaaS.
Taki katalog nie musi być idealny, ale musi być aktualizowany. Dobrym podejściem jest powiązanie go z repozytorium Infrastructure as Code oraz CMDB, jeśli istnieje.
Klasyfikacja: krytyczne, ważne, wspierające
Po zebraniu listy systemów potrzebna jest ich klasyfikacja. Technicznie każdy system można chronić w podobny sposób, ale ekonomicznie to nieracjonalne. Rozsądny podział to co najmniej trzy klasy:
Systemy krytyczne – bez nich kluczowe procesy biznesowe stają. Typowo: system transakcyjny, system płatności, główny portal klienta, kluczowe integracje z partnerami.
Systemy ważne – ich brak powoduje znaczne utrudnienia, ale istnieją obejścia (np. manualne). Przykłady: CRM, system ticketowy, wewnętrzne narzędzia raportowe.
Systemy wspierające – aplikacje wewnętrzne, środowiska testowe, narzędzia analityczne, których chwilowa niedostępność jest akceptowalna.
Klasyfikację przeprowadza się z udziałem właścicieli biznesowych i szefów jednostek. Z technicznego punktu widzenia często widać zależności, których biznes nie dostrzega (np. krytyczny system korzysta z „niszowej” bazy danych). Dlatego dyskusja powinna łączyć perspektywę IT i biznesu.
Analiza ryzyka: techniczne, procesowe i ludzkie źródła problemów
Analiza ryzyka w środowisku chmurowym wykracza poza awarie serwerów. Źródła ryzyka można podzielić na kilka grup:
Ryzyka techniczne – awarie usług chmurowych, problemy sieciowe między regionami, błędy w usługach zarządzanych, wyczerpanie limitów (quota) na zasoby.
Ryzyka procesowe – brak lub słabe procedury zmian, niewystarczające testy, brak przeglądów uprawnień, niespójne procesy zarządzania wersjami IaC.
Ryzyka ludzkie – błędy administracyjne, nieautoryzowane działania, ataki z użyciem przejętych kont, zbyt szerokie uprawnienia użytkowników.
Analiza ryzyka powinna wskazywać, które zagrożenia mogą doprowadzić do przerwy przekraczającej zakładane RTO lub utraty danych większej niż przyjęte RPO. To one wyznaczają priorytety w projektowaniu architektury DR i wyborze narzędzi.
Najczęściej zadawane pytania (FAQ)
Co to jest Disaster Recovery w chmurze i czym różni się od wysokiej dostępności (HA)?
Disaster Recovery (DR) w chmurze to zestaw procedur, architektury i narzędzi, które mają umożliwić odtworzenie systemów po zdarzeniu katastroficznym: utracie danych, awarii całego regionu, poważnym błędzie konfiguracji czy ataku ransomware. Kluczowe jest przywrócenie działania do z góry określonego punktu w czasie (RPO) i w ustalonym czasie (RTO).
Wysoka dostępność (High Availability, HA) ma łagodzić skutki typowych, krótkotrwałych awarii – np. pad jednego serwera, chwilowe problemy w jednej strefie dostępności. DR zakłada, że scenariusz jest dużo gorszy: nie działa region, konfiguracja została zniszczona albo dane są zaszyfrowane. HA utrzymuje system „w ruchu”, a DR pozwala go „podnieść z gruzów”.
Dlaczego przejście do chmury nie załatwia automatycznie Disaster Recovery?
Dostawca chmury zapewnia infrastrukturę, redundancję sprzętu, izolację regionów i stref, a także podstawowe mechanizmy backupu czy replikacji. Nie projektuje jednak za klienta konkretnych scenariuszy odtworzeniowych, nie wybiera regionu zapasowego i nie decyduje, jakie dane oraz jak często mają być kopiowane.
W praktyce oznacza to, że samo uruchomienie aplikacji w chmurze – nawet w kilku strefach dostępności – rozwiązuje głównie kwestię wysokiej dostępności. DR trzeba zaprojektować osobno: dobrać RPO/RTO, włączyć i skonfigurować backupy, replikację między regionami, procedury przełączeń. Bez tego po poważnym incydencie może się okazać, że technicznie „dało się” odtworzyć system, ale nikt nie przygotował do tego planu.
Na czym polega model shared responsibility w kontekście Disaster Recovery?
Model shared responsibility dzieli odpowiedzialność między dostawcę chmury a klienta. Dostawca odpowiada za fizyczną infrastrukturę (centra danych, sieć, zasilanie, sprzęt) i bezpieczeństwo platformy. Klient zarządza tym, co uruchamia na tej platformie: konfiguracją usług, siecią wirtualną, kontami użytkowników, aplikacjami i danymi.
W obszarze DR wygląda to tak: dostawca udostępnia narzędzia (backup, replikacja, multi‑region), ale to klient decyduje, czy je włączyć, jak je skonfigurować i monitorować. Jeśli po incydencie pojawia się pytanie „dlaczego nie mamy kopii?”, odpowiedź najczęściej dotyczy decyzji (lub ich braku) po stronie klienta, a nie awarii samej platformy chmurowej.
Jakie są najczęstsze scenariusze katastroficzne w środowisku chmurowym?
Poza rzadkimi, ale możliwymi awariami całego regionu, dużą część poważnych incydentów powodują błędy człowieka i konfiguracji. Przykładem jest błędny skrypt Terraform, który usuwa produkcyjne zasoby, albo masowe usunięcie danych przez źle przygotowane narzędzie migracyjne.
Często spotykane są także ataki ransomware i przejęcia kont administracyjnych – ich skutkiem może być zaszyfrowanie lub usunięcie danych, a nawet skasowanie backupów. Pytanie kontrolne brzmi: czy organizacja ma techniczną możliwość i procedury, aby w takim scenariuszu odtworzyć środowisko w innym regionie lub z izolowanych kopii?
Co oznaczają RPO i RTO w Disaster Recovery w chmurze?
RPO (Recovery Point Objective) to maksymalny akceptowalny okres utraty danych, wyrażony w czasie. Jeśli RPO wynosi 30 minut, firma godzi się na to, że w razie awarii dane z ostatniego pół godziny mogą zniknąć i będą musiały zostać odtworzone inną drogą (np. ręcznie). To bezpośrednio przekłada się na częstotliwość backupów i replikacji.
RTO (Recovery Time Objective) określa, ile czasu może upłynąć od rozpoczęcia scenariusza DR do przywrócenia działania systemu. Dla RTO = 2 godziny należy zaprojektować takie procedury i architekturę (np. pre‑konfigurowane środowisko w regionie zapasowym), żeby realne odtworzenie mieściło się w tym oknie czasowym.
Czym są RCO i RLO i po co je definiować w planie DR?
RCO (Recovery Capacity Objective) opisuje, jaką moc i pojemność ma mieć środowisko po odtworzeniu. Może to być 100% normalnej wydajności (pełne odtworzenie) albo np. 50–60% mocy, wystarczające do obsługi najważniejszych procesów. Ten parametr mocno wpływa na koszty – architektura active‑active spełniająca RCO = 100% jest znacznie droższa niż wariant „pilot light” z minimalnym środowiskiem w gotowości.
RLO (Recovery Level Objective) porządkuje poziom, na którym odtwarzamy usługę: czy przywracamy cały ekosystem (wiele aplikacji i integracji), pojedyncze systemy, konkretne mikrousługi, czy wyłącznie dane. Jasno zdefiniowane RLO ogranicza ryzyko nieporozumień, gdy część systemów obejmuje plan DR, a inne pozostają poza nim.
Jak przełożyć RPO i RTO na praktyczne scenariusze dla biznesu?
Najprościej jest rozmawiać nie o liczbach, ale o konkretnych sytuacjach. Przykład: „Co się dzieje, jeśli stracimy dane z ostatnich 30 minut? Czy jesteśmy w stanie odtworzyć zamówienia z maili, potwierdzeń płatności, raportów?” albo „Co, jeśli system będzie niedostępny przez 8 godzin – czy mamy alternatywny kanał obsługi klienta?”.
Takie pytania ujawniają realną wrażliwość procesów. Jeśli nawet 5 minut utraty danych jest nieakceptowalne, potrzebna jest agresywna replikacja lub architektura active‑active. Jeśli biznes jest w stanie funkcjonować z jednodniowym opóźnieniem, wystarczą rzadsze backupy i prostsze procedury odtwarzania. Kluczowa jest spójność: deklarowane RPO/RTO muszą odpowiadać skutkom, które firma jest gotowa przyjąć.
Opracowano na podstawie
ISO 22301:2019 Security and resilience – Business continuity management systems – Requirements. International Organization for Standardization (2019) – Norma BCM; definicje RTO/RPO, wymagania planów ciągłości i DR
NIST SP 800-34 Rev.1 Contingency Planning Guide for Federal Information Systems. National Institute of Standards and Technology (2010) – Przewodnik planowania ciągłości i DR, definicje RTO/RPO, analiza wpływu
AWS Disaster Recovery Workloads on AWS: Recovery in the Cloud. Amazon Web Services – Modele DR w chmurze (backup and restore, pilot light, warm standby, multi-site)
Azure Well-Architected Framework – Reliability. Microsoft Azure – Zalecenia HA i DR w Azure, RPO/RTO, regiony zapasowe i backup
Google Cloud Architecture Framework – Reliability. Google Cloud – Wytyczne projektowania niezawodności, DR w wielu regionach, cele RPO/RTO
Shared Responsibility in the Cloud. Cloud Security Alliance – Model współdzielonej odpowiedzialności, granice obowiązków dostawcy i klienta
ENISA Cloud Computing: Benefits, risks and recommendations for information security. European Union Agency for Cybersecurity (2009) – Ryzyka chmury, odpowiedzialność stron, potrzeba planów DR i backupu
IBM Redbooks: Disaster Recovery and Business Continuity. IBM – Przegląd koncepcji DR, różnica HA/DR, scenariusze katastroficzne i metryki
