Przykład fikcyjny. Nie opisuje żadnej konkretnej organizacji ani awarii.
Sytuacja
Operator pokazuje zielony raport z nocnych kopii. Na pytanie o odtworzenie aplikacji, plików i kolejki zespół odpowiada: „Kopie przecież są”. Właściciel usługi zakłada 30 minut do ponownego uruchomienia. Nikt nie sprawdził czasu pobrania kopii, dostępu do kluczy ani tego, czy dane z różnych systemów pasują do siebie po odtworzeniu.
Objawy
- Monitoring sprawdza, że zadanie kopii się zakończyło, ale nie odczytuje danych z kopii.
- Procedura zawiera nazwę narzędzia, a nie kolejność odtworzenia zależności i osoby upoważnione do decyzji.
- RPO i RTO zapisano dla „systemu”, chociaż baza, pliki i wiadomości mają inne harmonogramy.
- Ostatnia próba odbyła się na małej próbce sprzed kilku lat; nie mierzono pełnej ścieżki użytkownika.
Konsekwencja
Po awarii kopia może być nieczytelna, klucz niedostępny albo odtworzone załączniki mogą nie odpowiadać wpisom w bazie. Nawet sprawna kopia jednego elementu nie przywróci usługi jako całości. Zielony wskaźnik zadania jest wtedy miarą pracy harmonogramu, nie odporności architektury.
Lepsza decyzja
- Zapisz, co oznacza „usługa działa” z perspektywy użytkownika, i określ RPO oraz RTO dla tej ścieżki.
- Ustal retencję, integralność i dostępność kopii oraz kluczy także podczas awarii głównego regionu. Ogranicz dostęp i sprawdź możliwość odtworzenia w izolacji.
- Ćwicz całą procedurę na reprezentatywnej wielkości danych: baza, pliki, komunikaty, konfiguracja, routing. Odtwórz funkcję i wykonaj test transakcyjny.
- Zmierz osiągnięte cele, zapisz rozbieżności i właścicieli poprawek. Powtarzaj po istotnych zmianach i sprawdzaj, czy bieżące kopie dają się odczytać.
Ćwiczenie kosztuje czas i środowisko. Brak ćwiczenia również ma cenę, tylko rachunek przychodzi w najgorszym momencie.
Backup istnieje dopiero wtedy, gdy potrafisz z niego odtworzyć potrzebną usługę w wymaganym czasie.