Jak zapobiec blokowaniu zaplanowanych kopii zapasowych przez zadania czyszczenia Restic

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 Prevent Restic Prune Jobs From Blocking Scheduled Backups - Zima Store Online

Zapobiegaj kolizjom podczas czyszczenia, wyznaczając jednego właściciela konserwacji dla każdego repozytorium i przydzielając mu okno, w którym żaden klient kopii zapasowych nie może rozpocząć nowej pracy.

W przypadku współdzielonego repozytorium na domowym serwerze awaria zwykle zaczyna się wcześniej niż błąd blokady: kilka hostów ma własne harmonogramy konserwacji, jedna kopia zapasowa trwa dłużej, niż oczekiwano, a czyszczenie rozpoczyna się bez blokady obejmującej całe repozytorium. Odwróć tę kolejność zdarzeń. Scentralizuj czyszczenie, zarezerwuj wystarczająco dużo czasu, szeregować zadania poza Restic i skonfiguruj alerty dotyczące pominiętych lub opóźnionych uruchomień. Jeśli kolizja już wystąpiła, zatrzymaj nowe zadania i zastosuj minimalną ścieżkę odzyskiwania zamiast osłabiać mechanizm blokad.

Wyznacz jednego właściciela konserwacji dla każdego repozytorium

Przeszukaj każdego klienta i każdą usługę działającą po stronie repozytorium pod kątem poleceń konserwacyjnych Restic. Zapisz, kto odpowiada za polecenia forget, prune, check, unlock oraz alerty. Wyłącz zduplikowane harmonogramy czyszczenia i pozostaw jeden kontroler z poświadczeniami repozytorium oraz widocznością wszystkich klientów.

Wiele kopii zapasowych może być koordynowanych wokół jednego repozytorium, ale usuwanie wszystkich blokad przed czyszczeniem niweczy granicę bezpieczeństwa i może doprowadzić do niebezpiecznego nakładania się zadań, któremu harmonogram miał zapobiegać.

Kontrola własności kończy się powodzeniem, gdy tylko jeden host może rozpocząć konserwację całego repozytorium, a każdy klient kopii zapasowych wie, gdzie zgłaszać awarie. Jeśli urządzenie lub wrapper kopii zapasowej może uruchamiać ukrytą konserwację, wyłącz jego opcję automatyczną albo przed dalszymi działaniami włącz go do tego samego kontrolera.

Zarezerwuj okno na czyszczenie dłuższe niż najdłuższe zwykłe uruchomienie

Na podstawie ostatnich logów ustal najdłuższą zwykłą kopię zapasową, najdłuższe ostatnie czyszczenie, opóźnienia wybudzania klientów oraz zaległości ponownych prób. Zaplanuj czyszczenie po najpóźniejszym oczekiwanym zakończeniu kopii zapasowych i pozostaw czas na jego własne najdłuższe zwykłe wykonanie. Nie wybieraj północy tylko dlatego, że na jednym hoście wygląda na spokojną.

Plan retencji powinien również ograniczać wybór migawek według hosta lub tagu, aby retencja obejmująca wiele hostów nie wybierała niewłaściwych migawek, gdy repozytorium jest objęte jednym właścicielem konserwacji.

Jeśli kopie zapasowe często przekraczają proponowaną granicę, przesuń czyszczenie zamiast skracać okno tworzenia kopii. Jeśli czas czyszczenia rośnie ponad dostępną przerwę, zmniejsz częstotliwość fizycznego odzyskiwania miejsca, zbadaj przepustowość backendu albo użyj większego okna. Zapobieganie awariom zawodzi, gdy harmonogram zależy od tego, że każde zadanie zakończy się w swoim średnim czasie.

Wymuś wzajemne wykluczanie i widoczną politykę ponawiania prób

Użyj jednej zewnętrznej metody szeregowania, której przestrzegają wszystkie lokalne zadania: kolejności jednostek systemd, współdzielonego wrappera blokad albo kolejki kontrolowanej przez hosta konserwacji. Wrapper powinien odmówić uruchomienia późniejszego zadania lub je opóźnić, zachować własne blokady Restic i zapisywać czytelny status, który może być monitorowany za pomocą alertów.

Harmonogram Restic oparty na systemd może rozdzielać usługi cyklicznego tworzenia kopii i czyszczenia, dzięki czemu kolejność, kody wyjścia oraz logi pozostają widoczne.

Ustaw ograniczony czas między ponownymi próbami oraz maksymalne opóźnienie. Kopia zapasowa zablokowana przez konserwację powinna ponowić próbę po zakończeniu okna, a nie zniknąć do następnego dnia; czyszczenie zablokowane przez opóźnioną kopię powinno wygenerować alert i zostać przeniesione do kolejnego zatwierdzonego okna. Nigdy nie ustawiaj automatycznego wymuszonego odblokowania jako działania ponawiającego próbę.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Przetestuj zasady zapobiegania i zachowaj minimalną możliwość wycofania zmian

Przetestuj obie kolejności na repozytorium przeznaczonym do testów lub przykładowym zbiorze danych: najpierw uruchom kopię zapasową i zażądaj czyszczenia, a następnie najpierw uruchom czyszczenie i zażądaj kopii zapasowej. W obu przypadkach jedno zadanie powinno zaczekać lub zakończyć się w widoczny sposób, kontroler powinien ponowić próbę zgodnie ze skonfigurowaną polityką, a żadna blokada nie powinna zostać usunięta spod aktywnego procesu.

Po wdrożeniu sprawdź logi kolejnej zwykłej kopii zapasowej oraz poleceń forget i prune. Jeśli po konserwacji repozytorium działa w trybie tylko do odczytu, skorzystaj z oddzielnej ścieżki odzyskiwania po przerwanym czyszczeniu, zamiast rozluźniać blokadę zapobiegawczą.

Zasady działają, gdy dwa cykle kończą się bez nakładania zadań, opóźnione zadania ponawiają próby w widoczny sposób, alerty są generowane w przypadku pominiętych okien, a przykładowe przywracanie pozostaje prawidłowe. Jeśli zasady nie działają, najpierw wyłącz automatyzację czyszczenia i pozostaw zwykłe kopie zapasowe z normalnym mechanizmem blokad. Eskaluj problem, gdy żadne okno konserwacji nie mieści się w zmierzonym obciążeniu albo backend nie może niezawodnie ukończyć czyszczenia.