Dlaczego kopia zapasowa Restic zatrzymuje się, gdy inny host rozpoczyna usuwanie niepotrzebnych danych?

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.

Why Does a Restic Backup Stall When Another Host Starts Pruning? - Zima Store Online

Kopia zapasowa zwykle zatrzymuje się, ponieważ operacja prune wymaga wyłącznej kontroli nad współdzielonym repozytorium, więc drugi host nie może w tym momencie kontynuować pracy na tym samym stanie repozytorium.

W konfiguracji domowej z wieloma hostami najlepszym pierwszym wskaźnikiem jest kolejność zdarzeń: kopia zapasowa przebiega prawidłowo, inna maszyna uruchamia operację prune, a następnie kopia zapasowa czeka lub zgłasza blokadę. Zanim cokolwiek zmienisz, sprawdź właściciela blokady i aktywny dziennik konserwacji. Pozwól operacji prune zakończyć się albo zatrzymaj ją prawidłowo na hoście, który ją uruchomił; nigdy nie usuwaj jej blokady z klienta kopii zapasowej, który na nią czeka.

Potwierdź, że operacja prune jest dokładną przyczyną

Zapisz dziennik oczekującej kopii zapasowej oraz dziennik konserwacji hosta wykonującego prune wraz ze znacznikami czasu. Wyświetl blokady repozytorium i porównaj hosta, proces oraz stan wyłączności z zadaniem prune. Przyczyna jest potwierdzona, gdy postęp kopii zapasowej zatrzymuje się po uzyskaniu przez prune dostępu do repozytorium i wznawia po zwolnieniu tej blokady.

Operatorzy korzystający z jednego repozytorium na kilku hostach zgłaszają konflikty blokad podczas operacji prune, ponieważ operacja konserwacji konkuruje z niezależnymi harmonogramami kopii zapasowych.

Jeśli kopia zapasowa była już wcześniej powolna, host wykonujący prune nigdy nie uzyskał blokady albo oba dzienniki zatrzymują się na błędzie pamięci masowej, nie wymuszaj tej diagnozy. Sprawdź dostępność zaplecza, opóźnienia oraz sam proces tworzenia kopii zapasowej. Wyjaśnienie dotyczące blokady prune ma zastosowanie tylko wtedy, gdy zgadzają się wyzwalacz, właściciel blokady i moment jej zwolnienia.

Traktuj wyłączną blokadę jako granicę bezpieczeństwa

Operacja prune modyfikuje pamięć masową repozytorium, dlatego podczas działania wymaga spójnego widoku. Oczekująca kopia zapasowa nie musi być zawieszona w zwykłym sensie procesowym; może po prostu respektować blokadę konserwacji. Najpierw należy ustalić, czy prune robi postępy, a nie szukać sposobu na zignorowanie blokady przez kopię zapasową.

Współdzielone repozytorium wymaga jednego właściciela konserwacji, ponieważ konserwacja całego repozytorium wpływa na każdego klienta, nawet gdy dane źródłowe należą do różnych hostów.

Jeśli dzienniki prune posuwają się naprzód, a operacje wejścia-wyjścia repozytorium trwają, pozostaw blokadę i pozwól zadaniu się zakończyć. Jeśli zadanie rzeczywiście się zawiesiło, zatrzymaj je prawidłowo z hosta, który jest jego właścicielem, i zaczekaj na czyste zakończenie. Usunięcie blokady z innego klienta, gdy prune nadal zapisuje dane, zamienia kontrolowane oczekiwanie w niebezpieczne nakładanie się operacji.

Przywróć oczekującą kopię zapasową bez omijania blokad

Najmniej inwazyjnym rozwiązaniem jest zaczekanie na zakończenie prune. Jeśli kopia zapasowa ma ograniczoną politykę ponawiania, pozwól jej ponowić próbę po zniknięciu wyłącznej blokady. Gdy trzeba zatrzymać prune, użyj menedżera usług lub nadzorcy procesów na hoście, który jest jego właścicielem, zaczekaj na zamknięcie i potwierdź zmianę listy blokad przed ponownym uruchomieniem kopii zapasowej.

Retencję można ograniczyć do konkretnego hosta, ale fizyczne odzyskiwanie miejsca nadal jest operacją na repozytorium. Polityka retencji ograniczona do hosta zapobiega wybraniu niewłaściwych migawek, ale nie sprawia, że jednoczesne operacje prune stają się bezpieczne dla niezależnych klientów kopii zapasowych.

Ponów oczekującą kopię zapasową przy użyciu standardowego mechanizmu blokad. Jeśli zakończy się pomyślnie, naprawa odpowiada potwierdzonej przyczynie. Jeśli inna operacja prune uruchomi się natychmiast, wyłącz zduplikowany harmonogram konserwacji. Jeśli kopia zapasowa nadal się zatrzymuje mimo braku wyłącznej blokady, nie zwiększaj liczby ponowień, tylko wróć do diagnostyki zaplecza, sieci, skanowania źródła lub procesu.

-15% OFF

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

Single board computer zimaboard2

Ponownie sprawdź pierwotne nakładanie się operacji i wyznacz granicę

Użyj kontrolowanego okna czasowego i pełnych dzienników. Uruchom zwykłą kopię zapasową, a następnie wywołaj zaplanowany kontroler konserwacji i potwierdź, że nie powoduje on niebezpiecznego nakładania się operacji. Powtórz test w zamierzonej kolejności, zaczynając od prune, i sprawdź, czy kopia zapasowa czeka lub kończy działanie zgodnie ze skonfigurowaną polityką, a następnie pomyślnie wykonuje się po zwolnieniu blokady.

Jeśli przerwana operacja prune pozostawi repozytorium w innym stanie operacyjnym, postępuj zgodnie z diagnozą przerwanej operacji prune, zamiast traktować każdą późniejszą awarię jako zwykły konflikt.

Odzyskiwanie można uznać za pomyślne, gdy pierwotne nakładanie się operacji jest obsługiwane w przewidywalny sposób, kopia zapasowa później się kończy, prune kończy się prawidłowo, a przykładową migawkę można przywrócić. Eskaluj problem, jeśli blokada nigdy się nie odświeża lub nie zwalnia, wiele hostów wciąż uruchamia konserwację albo kontrola repozytorium zgłasza uszkodzenia. Takie wyniki wykraczają poza pojedynczą przyczynę w postaci aktywnej operacji prune.