Disaster recovery, backupy, RTO/RPO, failover i przede wszystkim pytanie, które wiele firm zadaje sobie dopiero po awarii: czy naprawdę potrafimy odtworzyć system i wrócić do pracy?
Awaria serwera. Uszkodzona baza danych. Błąd po wdrożeniu. Ransomware. Problemy z dostawcą infrastruktury. Przypadkowe usunięcie danych. Awaria całego regionu.
Scenariuszy jest wiele. Problem polega na tym, że większość firm przygotowuje się przede wszystkim na to, żeby awaria się nie wydarzyła.
A znacznie rzadziej przygotowuje się na sytuację, w której jednak się wydarzy.
To właśnie jest obszar disaster recovery.
I tutaj pojawia się podstawowe pytanie: jeżeli Twoja aplikacja przestanie działać dzisiaj o 14:00, to ile czasu potrzebujesz, żeby ją uruchomić ponownie i ile danych możesz przy tym stracić?
Jeżeli odpowiedź brzmi „mamy backup”, to jeszcze nie jest odpowiedź na to pytanie.
Backup to nie disaster recovery
Backup jest kopią danych. Disaster recovery jest procesem odzyskiwania działania systemu.
To bardzo ważne rozróżnienie.
Możesz mieć wykonywane codziennie kopie bazy danych, a mimo to nie wiedzieć:
-
czy ostatnia kopia jest poprawna,
-
czy można ją odtworzyć,
-
ile potrwa odtworzenie,
-
czy po odtworzeniu baza będzie współpracowała z aktualną wersją aplikacji,
-
czy odtworzysz również konfigurację systemu,
-
czy posiadasz wszystkie klucze, certyfikaty i sekrety potrzebne do uruchomienia środowiska,
-
czy infrastruktura potrzebna do uruchomienia aplikacji nadal jest dostępna,
-
kto ma wykonać poszczególne kroki,
-
czy cały proces mieści się w czasie akceptowalnym biznesowo.
NIST wprost wskazuje na potrzebę testowania odtwarzania kopii, a aktualne wytyczne AWS również traktują okresowe testy recovery jako sposób sprawdzenia, czy backup faktycznie pozwala osiągnąć założone RTO i RPO.
Dlatego backup jest elementem strategii recovery, a nie jej pełnym odpowiednikiem.
Najważniejsze pytanie: co stanie się po awarii?
Wyobraźmy sobie sklep internetowy.
O 10:17 baza danych przestaje odpowiadać.
Serwer aplikacji nadal działa, ale użytkownicy nie mogą się zalogować. Nie działają zamówienia. Panel administracyjny przestaje odpowiadać. System płatności nie otrzymuje prawidłowych informacji.
Zespół sprawdza sytuację.
Okazuje się, że ostatni backup bazy wykonano o 8:00.
Teoretycznie dane można odzyskać.
Ale wtedy pojawiają się kolejne pytania;
- Czy wiadomo, gdzie znajduje się kopia?
- Czy wiadomo, jak ją przywrócić?
- Czy osoba, która potrafi to zrobić, jest dostępna?
- Czy backup jest kompletny?
- Czy konfiguracja aplikacji odpowiada wersji zapisanej w kopii?
- Czy po odtworzeniu baza będzie działała z aktualną aplikacją?
- I najważniejsze: ile czasu zajmie przywrócenie działania sklepu?
Jeżeli nikt wcześniej tego nie sprawdził, odpowiedź może być zaskoczeniem.
RTO - ile przestoju jesteśmy w stanie zaakceptować?
RTO, czyli Recovery Time Objective, określa maksymalny akceptowalny czas odzyskania systemu po awarii.
Przykładowo: RTO = 4 godziny oznacza, że organizacja zakłada możliwość przywrócenia działania systemu w ciągu maksymalnie czterech godzin.
Nie oznacza to jednak, że każda aplikacja powinna mieć RTO wynoszące cztery godziny.
Dla wewnętrznego systemu używanego kilka razy dziennie taki czas może być akceptowalny. Dla platformy sprzedażowej działającej 24/7 może oznaczać bardzo poważne straty.
RTO powinno więc wynikać z biznesu, a nie z tego, co aktualnie oferuje infrastruktura.
NIST definiuje RTO jako czas, przez jaki system może pozostawać w fazie odzyskiwania, zanim wpłynie to negatywnie na działalność organizacji.
RPO - ile danych możemy stracić?
Drugim podstawowym parametrem jest RPO, czyli Recovery Point Objective.
RPO odpowiada na pytanie: jak daleko wstecz możemy cofnąć się z danymi po awarii?
Przykład: RPO = 1 godzina oznacza, że organizacja akceptuje potencjalną utratę maksymalnie około godziny danych.
Jeżeli system ulegnie awarii o 15:00, a ostatnia możliwa do wykorzystania kopia pochodzi z 14:00, właśnie taki scenariusz mieści się w założonym RPO. Ale jeśli backup wykonywany jest raz na dobę, trudno oczekiwać RPO na poziomie jednej godziny.
RPO wpływa więc bezpośrednio na sposób wykonywania kopii, replikacji danych i projektowania infrastruktury.
RTO mówi nam przede wszystkim jak długo możemy być niedostępni.
RPO mówi ile danych możemy stracić.
Te dwa parametry powinny być ustalone razem z biznesem, ponieważ ich osiągnięcie wiąże się z kosztami i rozwiązaniami technicznymi. Microsoft również podkreśla, że RTO i RPO powinny wynikać z rzeczywistych wymagań biznesowych, a nie z abstrakcyjnego założenia „zero przestoju i zero utraty danych”.
Backup może istnieć i nadal być bezużyteczny
To jeden z najbardziej niebezpiecznych mitów w IT.
„Backup wykonuje się poprawnie” nie oznacza automatycznie: „system można z niego odtworzyć”.
Kopia może być niekompletna. Może być uszkodzona. Może zawierać dane, których nie da się prawidłowo wykorzystać. Może być wykonana w sposób, który nie pozwala odtworzyć całego środowiska.
Dlatego backup trzeba testować przez rzeczywiste odtworzenie.
Nie wystarczy sprawdzić, czy plik istnieje.
Trzeba go przywrócić.
Uruchomić system.
Sprawdzić dane.
Zweryfikować zależności.
Sprawdzić konfigurację.
Zmierzć czas.
I odpowiedzieć na pytanie, czy wynik odpowiada założeniom RTO i RPO.
AWS jako typowy błąd wskazuje właśnie przywracanie backupu bez sprawdzenia, czy odtworzony zasób faktycznie działa i czy można korzystać z odzyskanych danych.
Failover - kiedy nie chcemy czekać na odtworzenie
Nie każda aplikacja może pozwolić sobie na kilka godzin oczekiwania na przywrócenie. W takich przypadkach stosuje się między innymi mechanizmy failover.
Failover oznacza przełączenie działania z podstawowego środowiska na przygotowane środowisko zapasowe.
Może to być:
-
zapasowy serwer,
-
druga strefa dostępności,
-
drugi region,
-
replika bazy danych,
-
środowisko standby,
-
alternatywna infrastruktura gotowa do uruchomienia.
W najprostszym modelu aplikacja działa w jednym miejscu, a w razie awarii uruchamiamy środowisko zapasowe. W bardziej zaawansowanych rozwiązaniach część infrastruktury działa równolegle i jest przygotowana do przejęcia ruchu.
Nie istnieje jednak jedna strategia odpowiednia dla wszystkich.
Backup i restore są zwykle tańsze, ale mogą oznaczać dłuższy czas odzyskiwania. Rozwiązania typu warm standby czy aktywna redundancja mogą znacząco skrócić recovery, ale wymagają większych nakładów i bardziej złożonej infrastruktury.
Failover też trzeba testować
Tutaj pojawia się kolejny problem.
Firma może mieć środowisko zapasowe, ale nie używała go od dwóch lat;
- Czy nadal działa?
- Czy konfiguracja odpowiada produkcji?
- Czy ma wystarczającą wydajność?
- Czy wszystkie usługi są dostępne?
- Czy certyfikaty są aktualne?
- Czy DNS przełączy się prawidłowo?
- Czy aplikacja połączy się z bazą?
- Czy mechanizm autoryzacji będzie działał?
- Czy zespół wie, co dokładnie powinien zrobić?
Dopiero test odpowiada na te pytania.
AWS zaleca regularne testowanie failoveru właśnie po to, żeby zweryfikować działanie ścieżki odzyskiwania oraz sprawdzić, czy rzeczywiste RTO i RPO odpowiadają założeniom.
Środowisko disaster recovery, którego nigdy nie testowano, jest częściowo tylko założeniem.
Disaster recovery to nie tylko infrastruktura
Łatwo patrzeć na DR wyłącznie przez pryzmat serwerów.
To błąd.
Recovery obejmuje również:
- Dane
Czy wszystkie istotne dane są objęte ochroną? - Aplikację
Czy posiadamy właściwą wersję kodu i możliwość jej wdrożenia? - Konfigurację
Czy wiemy, jakie ustawienia są potrzebne do uruchomienia systemu? - Sekrety i certyfikaty
Czy mamy bezpieczny dostęp do kluczy, tokenów i certyfikatów? - Zależności zewnętrzne
Co stanie się, jeżeli niedostępny będzie zewnętrzny system płatności, API, dostawca tożsamości albo usługa SaaS? - Infrastrukturę
Czy mamy miejsce, na którym aplikację można uruchomić? - Ludzi
Czy wiadomo, kto podejmuje decyzję o uruchomieniu procedury? - Procedury
Czy istnieje konkretny runbook, czy recovery opiera się na wiedzy jednej osoby?
To ostatnie jest szczególnie istotne.
Jeżeli tylko jeden administrator wie, jak odtworzyć system, nie mamy jeszcze odpornej procedury. Mamy zależność od konkretnego człowieka.
Najgorszy moment na pisanie procedury recovery
To moment, kiedy system już nie działa.
Wtedy pojawia się presja czasu, stres, telefony od klientów i pytania zarządu.
Dlatego procedura powinna być przygotowana wcześniej.
Powinna określać między innymi:
-
kiedy uruchamiamy disaster recovery,
-
kto podejmuje decyzję,
-
jakie systemy mają najwyższy priorytet,
-
gdzie znajdują się backupy,
-
jak je odtworzyć,
-
jakie zależności trzeba uruchomić,
-
jak wygląda failover,
-
jak zweryfikować poprawność działania,
-
jak komunikować awarię,
-
kiedy można rozpocząć failback,
-
kto zatwierdza powrót do środowiska podstawowego.
W przypadku poważnej awarii nie powinno być miejsca na pytanie: „Co teraz robimy?”
Procedura powinna odpowiedzieć na to wcześniej.
DR powinno być testowane jak funkcja aplikacji
Dobrym podejściem jest traktowanie recovery podobnie jak testów oprogramowania. Nie wystarczy raz przygotować procedury.
System się zmienia.
Baza danych rośnie.
Zmieniają się zależności.
Dochodzi nowa infrastruktura.
Zmieniają się wersje aplikacji.
Pojawiają się nowe integracje.
Zmieniają się uprawnienia.
Dlatego strategia recovery również wymaga ciągłego sprawdzania.
Test można zacząć od prostego scenariusza: „Baza danych została utracona. Odtwórzmy ją z ostatniej kopii.”
Później można przejść do bardziej złożonych scenariuszy:
- „Serwer aplikacji nie działa.”
- „Całe środowisko produkcyjne jest niedostępne.”
- „Dane zostały zaszyfrowane.”
- „Nie działa podstawowy region infrastruktury.”
- „Nie mamy dostępu do głównego administratora.”
Każdy taki test może ujawnić problemy, których nie widać podczas normalnej pracy systemu.
Czy każda aplikacja potrzebuje zaawansowanego disaster recovery?
Nie.
I to również jest ważne.
Projektowanie infrastruktury odpornej na każdy możliwy scenariusz może być nieproporcjonalnie drogie.
Jeżeli awaria aplikacji wewnętrznej może oznaczać godzinę niedogodności, niekoniecznie potrzebujemy infrastruktury active-active w kilku regionach. Jeżeli jednak awaria systemu oznacza zatrzymanie sprzedaży, produkcji, obsługi klientów albo krytycznego procesu biznesowego, sytuacja wygląda zupełnie inaczej.
Najpierw należy określić wpływ awarii na biznes.
Dopiero później dobierać technologię.
To może prowadzić do różnych rozwiązań:
Backup + restore
Prostsze i tańsze rozwiązanie dla systemów o niższej krytyczności.
Warm standby
Środowisko zapasowe jest częściowo przygotowane i może zostać szybko uruchomione.
Hot standby
Środowisko zapasowe działa w większym stopniu równolegle i jest gotowe do przejęcia obciążenia.
Active-active
Dwa środowiska mogą jednocześnie obsługiwać ruch, ograniczając zależność od pojedynczego miejsca awarii.
Wybór rozwiązania powinien wynikać z RTO, RPO, krytyczności systemu, kosztu przestoju i możliwości technicznych.
Checklista: czy Twoja aplikacja jest gotowa na awarię?
Warto odpowiedzieć sobie na kilka prostych pytań.
1. Czy mamy backup?
To dopiero początek.
2. Czy backup jest przechowywany w sposób chroniący go również przed awarią środowiska produkcyjnego?
3. Czy kiedykolwiek wykonaliśmy pełne odtworzenie?
4. Ile faktycznie trwa restore?
5. Czy znamy RTO?
6. Czy znamy RPO?
7. Czy potrafimy odtworzyć nie tylko dane, ale również aplikację i jej konfigurację?
8. Czy mamy procedurę recovery?
9. Czy więcej niż jedna osoba potrafi ją wykonać?
10. Czy testowaliśmy failover?
11. Czy środowisko zapasowe jest aktualne?
12. Czy po ostatnich zmianach w systemie ponownie przetestowaliśmy recovery?
Jeżeli na kilka pytań odpowiadamy „nie wiem”, to jest bardzo dobry moment, żeby przyjrzeć się strategii disaster recovery.
Najważniejszy test brzmi: „Pokaż”
W IT bardzo łatwo powiedzieć:
- „Mamy backup.”
- „Mamy serwer zapasowy.”
- „Mamy procedurę.”
- „Mamy disaster recovery.”
- Ale bezpieczeństwo systemu nie powinno opierać się wyłącznie na deklaracjach.
Najważniejsze pytanie brzmi: Pokaż, że możesz go odtworzyć.
- Uruchom restore.
- Zmierz czas.
- Sprawdź dane.
- Przetestuj aplikację.
- Przeprowadź failover.
- Sprawdź procedurę.
- Powtórz test po istotnych zmianach.
Dopiero wtedy można powiedzieć, że strategia recovery została sprawdzona w praktyce.
Backup chroni dane. Recovery przywraca biznes
To chyba najważniejsza różnica.
Backup odpowiada na pytanie: „Czy mamy kopię?”
Disaster recovery odpowiada na znacznie trudniejsze pytanie: „Czy po awarii potrafimy wrócić do działania?”
A między jednym a drugim znajduje się cała architektura odzyskiwania: RPO, RTO, replikacja, backupy, restore, failover, konfiguracja, procedury, odpowiedzialność i regularne testy.
Dobrze zaprojektowany system nie zakłada, że awaria się nie wydarzy. Zakłada, że awaria kiedyś się wydarzy i trzeba będzie wiedzieć, co zrobić.
Bo prawdziwa odporność aplikacji nie polega na tym, że nigdy się nie psuje. Polega na tym, że kiedy coś pójdzie nie tak, organizacja potrafi wrócić do działania w sposób przewidywalny, kontrolowany i zgodny z wymaganiami biznesu.
Słowniczek
Disaster Recovery (DR) - strategia i procedury pozwalające odzyskać działanie systemów po poważnej awarii.
Backup - kopia danych przeznaczona do ich późniejszego odtworzenia.
Restore - proces odtwarzania danych lub systemu z kopii.
RTO (Recovery Time Objective) - maksymalny akceptowalny czas odzyskania systemu.
RPO (Recovery Point Objective) - maksymalna akceptowalna utrata danych wyrażona w czasie.
Failover - przełączenie działania systemu z podstawowego środowiska na zapasowe.
Failback - powrót działania do podstawowego środowiska po usunięciu przyczyny awarii.
Recovery test - test mający potwierdzić, że system można rzeczywiście odtworzyć zgodnie z przyjętymi założeniami.
Runbook - szczegółowa instrukcja postępowania w określonym scenariuszu awarii.
