Kopia bez próby odtworzenia

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

1. Zapisz, co oznacza „usługa działa” z perspektywy użytkownika, i określ RPO oraz RTO dla tej ścieżki.
2. 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.
3. Ćwicz całą procedurę na reprezentatywnej wielkości danych: baza, pliki, komunikaty, konfiguracja, routing. Odtwórz funkcję i wykonaj test transakcyjny.
4. 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.