Jak sprawdzić, czy błąd tworzenia kopii zapasowej wynika z repozytorium czy z plików źródłowych

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How to Tell Whether a Backup Failure Comes From the Repository or Source Files - Zima Store Online

Testuj odczyt repozytorium niezależnie z małego, stabilnego źródła, a następnie testuj podejrzane ścieżki źródłowe w nowym, tymczasowym repozytorium.

Decyzja ma znaczenie, gdy kopia zapasowa zatrzymuje się z powodu błędów odczytu, sum kontrolnych, uprawnień, pakietów lub indeksu. Dwa konkurencyjne stany to uszkodzenie repozytorium lub miejsca docelowego oraz błędy odczytu, uprawnień lub zmian w plikach źródłowych. Zacznij od zapisanej konfiguracji i danych tymczasowych, obserwuj jedną gałąź naraz i zatrzymaj się, jeśli test zwiększa ryzyko utraty danych, problemów z uprawnieniami lub dostępnością.

Oddziel uszkodzenie repozytorium lub miejsca docelowego od błędów odczytu, uprawnień lub zmian w plikach źródłowych

Zapisz środowisko przed wprowadzeniem jakichkolwiek zmian: wersje oprogramowania i oprogramowania układowego, identyfikatory urządzeń, ścieżkę montowania lub sieciową, wolne miejsce, uprawnienia oraz obserwowany objaw. Stan bazowy musi zachować wystarczająco dużo szczegółów, aby odtworzyć zatrzymanie kopii zapasowej z powodu błędów odczytu, sum kontrolnych, uprawnień, pakietów lub indeksu.

Pierwszą możliwością jest uszkodzenie repozytorium lub miejsca docelowego. Drugą są błędy odczytu, uprawnień lub zmian w plikach źródłowych. Aktualna sekwencja rozwiązywania problemów z Restic określa mechanizm lub granicę polecenia używaną w teście; nie zastępuje obserwacji z tego konkretnego serwera domowego.

Zapisz warunek akceptacji i warunek zatrzymania przed uruchomieniem testu rozróżniającego. Wynik pozytywny musi zmienić dowody przewidywane przez jedną gałąź, pozostawiając niepowiązane usługi bez zmian; wynik negatywny musi przywrócić system do zapisanego stanu, zamiast uruchamiać łańcuch spekulatywnych poprawek.

Uruchom jeden kontrolowany test rozróżniający

Użyj następującego testu rozróżniającego: uruchom sprawdzanie repozytorium i przywracanie kanarka, następnie wykonaj kopię zapasową stałego, czytelnego zestawu testowego i osobno sprawdź błędy źródłowe. Zachowaj stałe obciążenie, klienta, ścieżkę, zestaw plików i czas, aby wynik można było przypisać zmienionej zmiennej.

Użyj niezależnego przebiegu pracy z Restic, aby wybrać pole, które rzeczywiście może rozdzielić te gałęzie, a następnie zapisz jego znacznik czasu, kod zakończenia, tekst błędu, identyfikator urządzenia lub migawki, opóźnienie, przesłane bajty, uprawnienia i stan odzyskiwania. Pomyślne zakończenie polecenia nie wystarcza, gdy testowane twierdzenie dotyczy tożsamości, trwałości lub stanu aplikacji.

Powtórz test raz po ponownym uruchomieniu, ponownym połączeniu, ponownym zamontowaniu lub wyczyszczeniu pamięci podręcznej, jeśli takie zdarzenie było częścią pierwotnego stanu. Jeśli pierwszy przebieg jest destrukcyjny lub środowiska nie można przywrócić, zatrzymaj się i odtwórz test na tymczasowej kopii.

restic check
restic restore latest --include /canary --target /tmp/restore-test

Ustal, którą gałąź potwierdzają dowody

WYNIK POZYTYWNY: sprawdzanie repozytorium lub przywracanie kończy się błędem dla różnych źródeł albo zawodzą tylko określone ścieżki źródłowe, podczas gdy repozytorium pozostaje sprawne. Zapisz dokładną wersję, tożsamość i obciążenie, które zakończyły się powodzeniem, aby wniosek pozostał warunkowy, a nie stał się twierdzeniem uniwersalnym.

WYNIK NEGATYWNY: awarie sieci i pamięci wpływają na oba testy, więc odtwórz problem lokalnie, zanim uznasz którąkolwiek stronę za uszkodzoną. Wynik negatywny nie potwierdza automatycznie przeciwnej gałęzi, gdy na oba testy mogą wpływać sieć, pamięć, uprawnienia lub spójność źródła; odizoluj te wspólne zależności przed eskalacją.

WYJĄTEK LUB NIEJEDNOZNACZNY WYNIK: wstrzymaj destrukcyjne prace konserwacyjne, skopiuj dzienniki i zabezpiecz ostatni sprawny stan repozytorium. Zachowaj dzienniki i nie uruchamiaj poleceń naprawy, czyszczenia, niszczenia, partycjonowania ani rekurencyjnej zmiany właściciela, dopóki nie powstanie możliwa do odzyskania kopia.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Zastosuj dopasowane działanie i odtwórz pierwotną awarię

Zastosuj działanie dopasowane do zaobserwowanej gałęzi, a następnie powtórz pierwotny warunek zamiast jego ograniczonego zamiennika. Wniosek jest wiarygodny tylko wtedy, gdy sprawdzanie repozytorium lub przywracanie kończy się błędem dla różnych źródeł albo zawodzą tylko określone ścieżki źródłowe, podczas gdy repozytorium pozostaje sprawne przez dwa cykle lub przez odpowiedni restart, uśpienie, przerwanie albo przejście obciążenia.

Użyj rozmiaru pakietów Restic, aby sprawdzić najbliższy zależny przebieg pracy, ale pozostaw pierwotny wyzwalacz bez zmian. Niepowiązane zbiory danych, udziały, kontenery, użytkownicy i punkty odzyskiwania muszą zachować wcześniejszy dostęp i czas działania.

Granica zatrzymania jest wyraźna: jeśli awarie sieci i pamięci wpływają na oba testy, odtwórz problem lokalnie, zanim uznasz którąkolwiek stronę za uszkodzoną, wróć do ostatniej zweryfikowanej konfiguracji, zachowaj dowody i przejdź do dokładniejszego testu platformy lub sprzętu tylko wtedy, gdy gałąź jest powtarzalna.

Gdy docelowy wynik się utrzyma, porównaj go z częstotliwością weryfikacji, aby poprawka nie przeniosła ryzyka do sąsiedniej usługi. Pomyślny test docelowy z nową awarią kopii zapasowej, tożsamości, limitu czasu lub dostępności nadal oznacza nieudaną zmianę.

FAQ

W przypadku izolowania awarii kopii zapasowej pozostałe wyszukiwania zwykle dotyczą tego, czy pomyślne sprawdzenie repozytorium może potwierdzić zakres źródła, czy repozytorium należy natychmiast naprawić oraz jakie błędy źródłowe łatwo przeoczyć. Poniższe odpowiedzi oddzielają te przypadki brzegowe od głównej decyzji.

Granica akceptacji nie zmienia się: sprawdzanie repozytorium lub przywracanie kończy się błędem dla różnych źródeł albo zawodzą tylko określone ścieżki źródłowe, podczas gdy repozytorium pozostaje sprawne. Jeśli kolejny warunek zmieni system plików, tożsamość, ścieżkę sieciową lub wersję aplikacji, powtórz tylko test rozróżniający, którego dotyczy ta zmiana.

Przestań rozszerzać eksperyment, gdy awarie sieci i pamięci wpływają na oba testy, więc odtwórz problem lokalnie, zanim uznasz którąkolwiek stronę za uszkodzoną. W tym momencie wstrzymaj destrukcyjne prace konserwacyjne, skopiuj dzienniki i zabezpiecz ostatni sprawny stan repozytorium; zachowaj dowody przed eskalacją do właściciela platformy, pamięci masowej lub sprzętu.

Czy pomyślne sprawdzenie repozytorium może potwierdzić zakres źródła?

Nie. Potwierdza właściwości repozytorium, ale nie to, że każdy zamierzony plik źródłowy był możliwy do odczytania lub został uwzględniony.

Czy repozytorium należy natychmiast naprawić?

Nie, nie przed wykonaniem w miarę możliwości kopii bezpieczeństwa i potwierdzeniem klasy awarii.

Jakie błędy źródłowe łatwo przeoczyć?

Odmowy dostępu, znikające pliki, nieczytelne sektory, pliki rzadkie oraz problemy ze spójnością aplikacji mogą być ukryte w podsumowaniach.

Diagnoza jest zakończona, gdy to samo obciążenie sprawia, że dowody wskazują na uszkodzenie repozytorium lub miejsca docelowego albo na błędy odczytu, uprawnień lub zmian w plikach źródłowych, a dopasowane działanie usuwa pierwotny objaw bez tworzenia kolejnego. Jeśli żadna gałąź nie pozostaje powtarzalna, zachowaj dzienniki i zapisany stan; niepewność jest powodem do eskalacji, a nie do nakładania kolejnych poprawek.