Prawidłowo wykonana kopia zapasowa sama w sobie nie dowodzi, że aplikacja może ponownie świadczyć usługi. Może brakować klucza, zewnętrznej zależności, plików powiązanych z bazą danych albo procedury określającej kolejność ich odtwarzania. Testy odtwarzania po awarii aplikacji PHP pozwalają sprawdzić cały proces, zanim utrata lub uszkodzenie danych zmusi do przeprowadzenia go pod presją.
Celem nie jest zagwarantowanie, że przerwy w działaniu nigdy nie wystąpią, lecz uzyskanie informacji o tym, co można odtworzyć, ile to trwa i jakie przeszkody pozostają do usunięcia. Aby ćwiczenie było przydatne, trzeba określić jego zakres, odizolować środowisko, zweryfikować zarówno infrastrukturę, jak i działanie aplikacji oraz przypisać osoby odpowiedzialne za niezbędne usprawnienia.
Weryfikacja kopii zapasowej to nie to samo co przywrócenie usługi
Sprawdzenie kopii zapasowej może potwierdzić, że plik istnieje, ma wiarygodny rozmiar albo można go odczytać za pomocą danego narzędzia. To wartościowa kontrola, ale różni się od odtworzenia niezbędnych komponentów i wykazania, że aplikacja z nimi działa.
Pełne odtworzenie może obejmować bazę danych, pliki przesłane przez użytkowników, kod i konfigurację, a także usługi takie jak kolejki zadań, magazyn obiektowy, cache czy zadania zaplanowane. Może też zależeć od DNS, certyfikatów, uprawnień, rozszerzeń PHP i usług zewnętrznych. Jeśli któregoś z tych elementów brakuje albo nie pasuje do pozostałych, kopia może być prawidłowa, a usługa nadal nie będzie odtworzona.
Warto określić, co oznacza „odtworzenie” w przypadku każdej aplikacji. Może to oznaczać, że proces PHP się uruchamia, uprawnieni użytkownicy mogą się zalogować i przejść kluczowy proces albo zadania działające w tle są ponownie przetwarzane. Sama widoczność strony głównej nie wystarczy jako jedyne kryterium.
Przed rozpoczęciem określ zakres i kryteria powodzenia
Udokumentuj testowany scenariusz, na przykład utratę bazy danych, uszkodzenie plików lub niedostępność całego środowiska. Nie trzeba symulować wszystkich incydentów podczas jednej sesji. Określenie granic scenariusza pozwala wskazać komponenty wymagające odtworzenia oraz to, co wyraźnie nie wchodzi w zakres ćwiczenia.
Uzgodnij weryfikowalne kryteria z zespołami biznesowymi, technicznymi i operacyjnymi. Wśród praktycznych pytań są:
- Które funkcje muszą być ponownie dostępne, a które mogą poczekać?
- Do którego momentu dane powinny zostać odtworzone i jaka utrata zmian byłaby możliwa do zaakceptowania?
- Jak długo usługa może pozostawać niedostępna, zanim wpływ stanie się nieakceptowalny?
- Które zależności są częścią procesu odtwarzania, a które zostaną zastąpione bezpiecznymi zamiennikami?
- Kto zatwierdza wykonanie testu, weryfikuje wynik i informuje o problemach?
Parametry RPO (Recovery Point Objective) i RTO (Recovery Time Objective) mogą pomóc określić dopuszczalną utratę danych i czas przerwy w działaniu. Należy je uzgodnić w zależności od potrzeb i możliwości każdej usługi; nie ma jednej uniwersalnej wartości. Test pozwala porównać zaobserwowany czas i stan danych z tymi celami, ale pojedynczego wyniku nie należy traktować jako gwarancji na przyszłość.
Przygotuj odizolowane i bezpieczne środowisko
Przeprowadź odtwarzanie w środowisku oddzielonym od produkcji, stosując zabezpieczenia uniemożliwiające modyfikację rzeczywistych danych lub wysyłanie wiadomości do klientów. Jeśli to możliwe, odizoluj sieci i zablokuj lub zastąp integracje, które mogłyby realizować płatności, wysyłać e-maile, publikować zdarzenia albo modyfikować systemy zewnętrzne. Poinformuj uczestników, że jest to test.
Odtworzone dane mogą zawierać informacje wrażliwe. Stosuj odpowiednie zasady kontroli dostępu, przechowywania i ochrony danych; ogranicz liczbę osób mogących uzyskać dostęp do środowiska oraz czas jego dostępności. Nie używaj ponownie poświadczeń produkcyjnych. Zarządzaj testowymi sekretami w kontrolowany sposób i sprawdź, czy odtworzone pliki nie ujawniają ich w logach, repozytoriach ani publicznie dostępnych katalogach.
Zapisz warunki początkowe: datę i punkt kopii zapasowej, wymagane wersje kodu i konfiguracji, dostępne zasoby oraz różnice między środowiskiem testowym a produkcyjnym. Inna wersja PHP, brakujące rozszerzenia lub odmienne uprawnienia mogą wpłynąć na wynik. Takie rozbieżności należy odnotować, a nie mylić z powodzeniem lub niepowodzeniem samej kopii.
Odtwórz wszystkie niezbędne komponenty
Postępuj zgodnie z udokumentowaną procedurą, nawet jeśli znasz szybszy sposób. Test ma właśnie sprawdzić, czy instrukcje są wystarczające, aby inna osoba mogła odtworzyć usługę. Zapisuj kolejność i czas trwania każdego kroku, ręcznie wykonywane polecenia, podjęte decyzje oraz wszelkie nieprzewidziane interwencje.
Możliwa sekwencja, którą należy dostosować do każdej architektury, obejmuje odtworzenie infrastruktury i konfiguracji, przywrócenie bazy danych i plików, wdrożenie zgodnej wersji kodu oraz podłączenie niezbędnych zależności. W przypadku PHP sprawdź, zależnie od potrzeb, konfigurację serwera WWW i PHP-FPM, wymagane rozszerzenia, zmienne środowiskowe, uprawnienia do zapisu oraz zadania zaplanowane. Sprawdź również kolejki, magazyn obiektowy i procesy workerów, jeśli aplikacja z nich korzysta.
Nie uruchamiaj automatycznie migracji ani procesów odbudowy danych bez poznania ich wpływu na odtworzoną kopię. Upewnij się, że poświadczenia wskazują wyłącznie usługi testowe, a zadania cron nie wywołują skutków zewnętrznych. Jeśli odtworzenie wymaga ręcznej interwencji, uwzględnij ją w rzeczywistym czasie trwania procesu i potraktuj jako możliwy obszar do usprawnienia.
Weryfikuj integralność i działanie, a nie tylko uruchomienie
Kontrole powinny obejmować dane i ścieżki funkcjonalne. Zacznij od weryfikacji technicznych: łączności z bazą danych, stanu procesów, dostępnego miejsca, logów błędów i odpowiedzi usług wewnętrznych. Następnie sprawdź, czy przechowywane pliki i odwołania do nich są zgodne oraz czy ważne relacje i ograniczenia bazy danych nadal są spójne.
Wybierz zapytania i ścieżki reprezentatywne dla rzeczywistego sposobu korzystania z aplikacji. Możesz na przykład sprawdzić, czy da się odnaleźć znany obiekt, zalogować się na konto testowe i wykonać operację, która nie wywołuje skutków zewnętrznych. Jeśli aplikacja obsługuje przesyłane pliki, sprawdź, czy można je odzyskać i powiązać z odpowiednimi rekordami. Jeśli używa kolejek, sprawdź, czy oczekujące zadania są obsługiwane zgodnie z oczekiwaniami i nie są przypadkowo przetwarzane dwukrotnie.
Zachowaj wystarczające dowody, aby można było powtórzyć ocenę: wyniki zapytań, wykonane kroki, zaobserwowane błędy oraz czas rozpoczęcia i zakończenia. Sam zapis „działa” nie wystarczy. Z góry określ, które kontrole oznaczają zaliczenie testu, a które są blokujące. Aplikacji, która odpowiada, ale wyświetla niekompletne dane lub nie obsługuje krytycznych operacji, nie należy uznawać za odtworzoną, jeśli obowiązują bardziej rygorystyczne kryteria.
Mierz, poprawiaj i powtarzaj test z odpowiednią częstotliwością
Mierz czas od uzgodnionego początku do spełnienia kryteriów odtworzenia, a nie tylko czas przywracania bazy danych. Jeśli ułatwia to analizę, rozdziel czas oczekiwania, pracę automatyczną, kroki ręczne i weryfikację. Porównaj wynik z uzgodnionymi celami i wskaż niespełnione założenia, takie jak niedostępne uprawnienia lub nieaktualna dokumentacja.
Raport powinien zawierać zakres, odtworzony punkt, wyniki poszczególnych kontroli, zaobserwowane czasy, incydenty, podjęte decyzje i osoby odpowiedzialne za działania naprawcze. Nadaj priorytet działaniom ograniczającym blokady: automatyzacji powtarzalnych kroków, aktualizacji instrukcji, poprawie uprawnień, przeglądowi zależności lub usprawnieniu strategii tworzenia kopii zapasowych. Wyznacz terminy działań następczych i powtórz test w objętym problemem zakresie, aby sprawdzić, czy poprawka go rozwiązała.
Częstotliwość zależy od ryzyka, zmian w architekturze i możliwości operacyjnych. Można łączyć częste częściowe odtwarzanie — na przykład bazy danych lub plików — z ćwiczeniami pełnego odtwarzania i różnymi scenariuszami. Warto także powtórzyć test po istotnych zmianach systemu kopii zapasowych, infrastruktury lub zależności. Udany test dostarcza informacji o konkretnym scenariuszu i określonych warunkach; nie gwarantuje wyniku w przypadku wszystkich przyszłych incydentów.
