Przećwicz przywracanie wspólnej wiki.

Zdecyduj, co będzie uznane za działający notatnik

Użyj przykładowej wiki warsztatowej z inwentarzem usług. Jej kryteria sukcesu są konkretne: redaktor może znaleźć i zmienić stronę testową, czytelnik może wyświetlić dozwolone instrukcje, prywatna książka organizacyjna pozostaje ukryta, a załączony diagram się otwiera. Użyj tych sprawdzeń jako planu testu przed otwarciem kopii zapasowej.

Wybierz świadków, którzy istnieli w momencie tworzenia wybranej kopii zapasowej. Nowo utworzona strona nie może dowodzić, że starsza kopia zapasowa jest niekompletna.

Zidentyfikuj dokładny zestaw odzyskiwania

Zapisz identyfikator kopii zapasowej i znacznik czasu na arkuszu wyników. Uwzględnij konfigurację aplikacji, dane bazy danych, załączniki oraz informacje o oprogramowaniu potrzebne do ich interpretacji. Jeśli czasy ich przechwycenia się różnią, zbadaj, jak Twoja procedura tworzenia kopii zapasowych utrzymuje ich spójność, zanim rozpoczniesz ćwiczenie.

W przypadku repozytorium restic wybierz jawny snapshot lub starannie sprawdź filtry używane z latest. Jego opcja --path wybiera snapshot; nie ogranicza przywracanych plików. Przywracanie może nadpisać istniejące pliki, co jest kolejnym powodem, by użyć pustego, dedykowanego celu. Dokumentacja restic restore.

Odróżnij sprawdzanie repozytorium od odzyskiwania aplikacji. Domyślny restic check bada strukturę repozytorium; check --read-data odczytuje również przechowywane dane pakietów i może zużyć znaczny transfer i czas. Żadne z nich nie sprawdza, czy członek może korzystać z Twojej wiki. sprawdzenia integralności restic.

Ucisz testową kopię, zanim wystartuje

Trzymaj produkcyjne hosty baz danych, ścieżki przechowywania i wychodzące poświadczenia poza konfiguracją testową. Niech drugi opiekun porówna każde miejsce docelowe z mapą usług. Potwierdź, że cel jest osobny przed każdą operacją przywracania, która zapisuje pliki lub obiekty bazy danych.

• Ogranicz dostęp do osób przeprowadzających ćwiczenie.
• Nie zmieniaj produkcyjnych rekordów DNS.
• Zablokuj wychodzącą dostawę lub zastąp ją zatwierdzonym miejscem przechwytywania.
• Wyłącz webhooki, zaplanowane integracje i workery kolejek, dopóki ich zachowanie testowe nie zostanie zdefiniowane.
• Sprawdź, czy linki i przekierowania w przeglądarce nie mogą po cichu przenieść testera z powrotem do środowiska produkcyjnego.

Traktuj przywrócone dane tak samo wrażliwie jak oryginał. Izolacja to operacyjne sprawdzenie do wykazania, a nie etykieta przypięta do katalogu. Jeśli nie możesz zweryfikować miejsc docelowych ani kontroli, zatrzymaj się przed uruchomieniem aplikacji.

Przywracaj elementy w przemyślanej kolejności

Postępuj zgodnie z instrukcjami przywracania dla metody instalacji i wersji ze swojego spisu. W przykładzie BookStack oficjalna procedura obejmuje osobne przywrócenie bazy danych i plików, zachowanie oryginalnego APP_KEY, oraz dostosowanie adresu URL aplikacji, gdy adres się zmieni. Konfiguracje kontenerowe wymagają przywrócenia bazy danych przed uruchomieniem kontenera aplikacji. Sekwencja przywracania BookStack i uwagi konfiguracyjne.

1. Przygotuj dedykowane środowisko uruchomieniowe i cel bazy danych bez uruchamiania zwykłego ruchu członków.
2. Przywróć pasującą bazę danych i pliki; zachowaj oryginalną kopię zapasową bez zmian.
3. Zastosuj adresy środowiska testowego i ograniczone połączenia zewnętrzne.
4. Sprawdź wymagane własności i dostęp do plików zgodnie z instrukcjami instalacji aplikacji.
5. Uruchom usługę z działaniami wychodzącymi nadal kontrolowanymi, a następnie uruchom zaplanowane testy.

Najpierw odtworzenie zapisanej wersji pozwala skupić się na rutynowym ćwiczeniu. Jeśli ćwiczenie wymaga również zmiany wersji, udokumentuj jej ścieżkę migracji i punkt odtworzenia osobno. Nie traktuj nieplanowanej aktualizacji jako środka zaradczego na niewyjaśnioną awarię odtwarzania.

Sprawdź zarówno to, co działa, jak i to, co pozostaje zabronione

Uruchom testy czytelnika i edytora w oddzielnych sesjach przeglądarki, aby sesja administratora nie mogła ukryć błędu uprawnień. Przetestuj załącznik poprzez stronę i jego bezpośredni adres. Wyszukaj znaną frazę, przejdź przez link wewnętrzny i sprawdź jedną starszą wersję, która powinna znajdować się w kopii zapasowej.

Jeśli test zakończy się niepowodzeniem, zapisz pierwszą zaobserwowaną różnicę. Brakujący obraz sugeruje inne dochodzenie niż nieoczekiwane przekierowanie logowania lub zabronione połączenie z bazą danych. Zachowaj istotne dowody błędów, nie kopiując prywatnych treści ani poświadczeń do ogólnej notatki wsparcia. Napraw jedną zidentyfikowaną przyczynę i powtórz dotknięty test; nie zmieniaj uprawnień szeroko tylko po to, aby błąd zniknął.

Testuj pocztę e-mail wyłącznie wobec wybranego miejsca przechwytywania. BookStack oferuje akcję testowej wiadomości e-mail i dokumentuje, że niektóre błędy powiadomień pojawiają się w logach, a nie na stronie użytkownika. Przejrzyj te dowody, a także widoczny wynik. Kontrole poczty e-mail i zachowanie przy błędach w BookStack.

Zostaw uczciwy wynik dla następnej osoby

Service / test owner / reviewer:
Backup identifier / capture timestamp:
Application and database versions:
Isolated target / access restrictions:
Outbound actions disabled or redirected:
Test start / usable-service checkpoint / finish:
Reader / editor / private book / attachment results:
Search / links / revision / notification results:
Missing information or failed steps:
Corrective action / owner / next exercise:
Test data cleanup completed by:

Wpisz zaobserwowane czasy dopiero po wykonaniu pracy i powiedz, który punkt kontrolny każdy z nich mierzy. Pojedyncza udana próba jest dowodem dla tej kopii zapasowej i procedury; nie stanowi gwarancji odtworzenia dla innej awarii. Potwierdź oczyszczenie kopii testowej i jej przechwyconych wiadomości zgodnie z zasadami retencji grupy. Przekaż brakujące składniki z powrotem do inwentarza i użyj przenośnych eksportów danych aby przygotować osobną ścieżkę przenoszenia treści grupy.