Repozytorium Restic zablokowane po awarii: przyczyny, kontrole i rozwiązania

Repozytorium Restic może pozostać zablokowane, ponieważ inny proces nadal działa, awaria pozostawiła nieaktualny stan, backend opóźnił aktualizacje albo zadanie konserwacyjne wciąż utrzymuje wyłączną blokadę.

Na domowym serwerze z wieloma hostami niebezpieczne jest założenie, że ostatnia widoczna awaria utworzyła jedyną blokadę. Zadanie prune może nadal działać na innym hoście, kontener mógł uruchomić się ponownie zgodnie z tym samym harmonogramem, a magazyn obiektowy może nie pokazywać od razu najnowszego stanu. Zacznij od wstrzymania nowych harmonogramów i odczytania tożsamości blokady; usuwaj blokadę dopiero wtedy, gdy host, proces, czas i aktywność repozytorium wskazują, że operacja rzeczywiście się zakończyła.

Przed podjęciem działania odczytaj tożsamość blokady

Wstrzymaj nowe harmonogramy tworzenia kopii zapasowych, forget, check i prune na każdej maszynie, która może uzyskać dostęp do repozytorium. Wyświetl blokady i zapisz ich host, identyfikator procesu, użytkownika, czas utworzenia, czas odświeżenia oraz rolę wyłączną lub niewyłączną. Następnie sprawdź pasujący proces i dzienniki usług na wskazanym hoście, zamiast oceniać sytuację wyłącznie na podstawie wieku blokady.

Nieaktualne blokady często są skutkiem przerwanego procesu Restic, ale przerwany potok to tylko jedna z możliwych przyczyn. Proces, który otrzymał sygnał powodujący nieprawidłowe zakończenie, może pozostawić stan wyglądający podobnie do stanu zdalnego zadania, które nadal działa.

Jeśli PID jest aktywny, a wpisy w dziennikach pojawiają się na bieżąco, zaczekaj lub zatrzymaj zadanie za pośrednictwem menedżera usług; nie odblokowuj repozytorium, gdy proces nadal z niego korzysta. Jeśli procesu nie ma, a host nie uruchomił ponownie tego samego zadania, blokada staje się kandydatem do uznania za nieaktualną. Jeśli host jest nieosiągalny lub widok backendu jest niespójny, stan pozostaje niezweryfikowany i żadne destrukcyjne działanie nie jest uzasadnione.

Rozróżnij cztery sygnatury blokad

Aktywny zapisujący ma odpowiadający mu proces, bieżącą aktywność w dziennikach oraz odświeżaną blokadę. Nieprawidłowe zakończenie nie pozostawia aktywnego procesu, a znacznik czasu blokady pozostaje niezmieniony po zatrzymaniu hosta lub kontenera. Opóźnienie backendu występuje wtedy, gdy klienci nie zgadzają się co do listy blokad lub znaczniki czasu są opóźnione względem znanej aktywności repozytorium. Niedokończona konserwacja objawia się blokadą wyłączną oraz wciąż zmieniającym się dziennikiem check lub prune.

Ogólna kolejność rozwiązywania problemów z Restic utrzymuje blokady repozytorium, błędy prune i możliwe uszkodzenia jako osobne ścieżki, dzięki czemu rozwiązanie problemu nieaktualnej blokady nie zostanie zastosowane do awarii magazynu.

Testuj jedną sygnaturę naraz. Najpierw potwierdź aktywność, następnie porównaj znaczniki czasu i dzienniki, potem sprawdź dostępność backendu oraz zegar, a na końcu skontroluj konserwację. Jeśli nadal prawdopodobne są dwie sygnatury, pozostaw blokadę i zbadaj bezpieczniejszą możliwość; odblokowanie nie jest testem diagnostycznym, ponieważ zmienia zabezpieczenie, które próbujesz zrozumieć.

Usuń tylko potwierdzoną nieaktualną blokadę

Przed odblokowaniem jeszcze raz sprawdź każdego klienta, kontroler automatyzacji, hosta kontenera oraz usługę po stronie repozytorium. Zapisz bieżącą listę blokad i ostatnie dzienniki. Użyj standardowego polecenia usuwania nieaktualnej blokady, a nie opcji usuwającej wszystkie blokady lub wyłączającej blokowanie, ponieważ standardowa ścieżka została zaprojektowana tak, aby pozostawiać aktywne blokady.

Rzeczywista awaria spowodowana nieaktualną blokadą może zatrzymać wcześniej działający harmonogram kopii zapasowych, ale wiek jednego przypadku nie wyznacza uniwersalnego bezpiecznego progu usuwania.

Jeśli standardowe polecenie usunie nieaktualny wpis i żadna blokada nie pojawi się natychmiast ponownie, przejdź do wyświetlenia zawartości repozytorium w trybie tylko do odczytu. Jeśli polecenie odmówi, ponieważ blokada jest aktywna, zatrzymaj się i znajdź jej właściciela. Jeśli nowa blokada pojawi się od razu, nadal działa harmonogram lub ponownie uruchomiony kontener; wyłącz to źródło przed kolejną próbą naprawy.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Ponownie przetestuj pierwotną operację i obserwuj, czy problem powraca

Uruchom tę samą operację, która zakończyła się niepowodzeniem, rejestrując postęp i kod wyjścia. Obserwuj, jak pojawia się blokada, jak jest odświeżana podczas aktywności zadania i jak znika po prawidłowym zakończeniu. Następnie pozwól na wykonanie jednego zwykłego cyklu zgodnie z harmonogramem. Odtworzenie pierwotnego wyzwalacza daje więcej informacji niż samo pomyślne wyświetlenie zawartości repozytorium.

Jeśli po usunięciu blokady repozytorium stanie się tylko do odczytu lub konserwacja zakończy się niepowodzeniem, skorzystaj z osobnej ścieżki odzyskiwania po przerwanym prune, zamiast wielokrotnie odblokowywać repozytorium.

Odzyskiwanie można uznać za zakończone, gdy dwa cykle przy pierwotnym obciążeniu zostaną wykonane do końca, każda blokada będzie odświeżana podczas aktywności i usuwana po zakończeniu, a sprawdzenie repozytorium lub przykładowe przywrócenie będzie przebiegać prawidłowo. Eskaluj problem, jeśli blokady powracają po prawidłowym zakończeniu, klienci nie zgadzają się co do stanu backendu albo sprawdzenie zgłasza brakujące lub uszkodzone obiekty repozytorium. Przez cały czas trwania analizy pozostaw blokowanie włączone.