Planuj kopie zapasowe często, wykonuj operację forget za pośrednictwem jednego kontrolera repozytorium, a prune uruchamiaj rzadziej w ramach wyłącznego okna konserwacyjnego. Nie pozwalaj, aby każdy host samodzielnie obsługiwał wszystkie trzy zadania.
Współdzielone repozytorium domowego serwera wymaga dwóch rodzajów harmonogramu: punktów odzyskiwania dla poszczególnych hostów oraz konserwacji obejmującej całe repozytorium. Twórz harmonogram na podstawie zmierzonych czasów trwania i celów odzyskiwania, a nie stałych przykładów z internetu. Scentralizuj retencję i prune, prawidłowo grupuj migawki, jawnie określaj kolejność jednostek oraz zapewnij ponowienie i alert dla każdego pominiętego zadania. Harmonogram jest kompletny dopiero wtedy, gdy dwa cykle i przykładowe odtworzenie potwierdzą, że retencja i blokady działają zgodnie z założeniami.
Zinwentaryzuj każde zadanie, właściciela i najdłuższy typowy czas trwania
Utwórz jedną tabelę dla każdej operacji, która korzysta z repozytorium: backup, forget, prune, check, unlock, wyświetlanie migawek i test odtwarzania. Zapisz hosta inicjującego operację, polecenie lub wrapper, dane uwierzytelniające, typowy i najdłuższy niedawno zmierzony czas trwania, limit czasu, regułę ponawiania oraz miejsce docelowe alertów. Uwzględnij zadania ukryte w aplikacjach do tworzenia kopii zapasowych lub interfejsach NAS.
Współdzielone repozytorium wymaga konserwacji na poziomie repozytorium, a nie jednej kopii dla każdego klienta. Praktyczne praktyki Restic dla wielu hostów przypisują operacje forget, prune i check do repozytorium tylko raz, jednocześnie grupując retencję według odpowiednich hostów i ścieżek.
Skonsoliduj zduplikowane zadania konserwacyjne pod jednym kontrolerem. Zachowaj obsługę kopii zapasowych po stronie poszczególnych hostów, jeśli ułatwia to dostęp do źródeł, ale wymagaj od każdego hosta raportowania kontrolerowi stanu rozpoczęcia i zakończenia. Jeśli zadanie nie ma zmierzonego czasu trwania ani właściciela, najpierw je obserwuj, zanim wyznaczysz wokół niego okno konserwacyjne.
Najpierw ustal częstotliwość kopii zapasowych, a następnie zakres operacji forget
Wybierz częstotliwość tworzenia kopii zapasowych dla każdego hosta na podstawie ilości zmian, na których utratę możesz sobie pozwolić, oraz typowego czasu trwania kopii. Rozłóż w czasie duże skanowania źródeł, jeśli konkurują o sieć lub pamięć masową, ale nie rozdzielaj zadań wyłącznie po to, aby wykres wyglądał schludnie. Najdłuższa typowa kopia zapasowa powinna wyznaczać najwcześniejszy początek konserwacji.
Uruchamiaj forget z poziomu kontrolera repozytorium i sprawdzaj w trybie podglądu jego wybór, używając zamierzonego grupowania hostów, ścieżek i tagów. Nieoczekiwane grupowanie według kalendarza może sprawić, że retencja usunie więcej punktów przywracania, niż wynikałoby to z prostego odczytania liczby zachowywanych kopii.
Podczas projektowania harmonogramu zachowaj logiczne rozdzielenie operacji forget i fizycznego prune. Podejrzenie zasad retencji może być wykonywane po pomyślnym zakończeniu kopii zapasowej lub w osobnej fazie kontrolera, natomiast prune powinno otrzymać dłuższe, wyłączne okno. Nie dołączaj prune do kopii zapasowej każdego hosta tylko dlatego, że jedno polecenie może połączyć obie operacje.
Umieść prune i check w oknach obejmujących całe repozytorium
Uruchamiaj prune rzadziej niż kopie zapasowe i zazwyczaj rzadziej niż forget, ponieważ fizyczne czyszczenie repozytorium może trwać znacznie dłużej i blokować inne zadania. Umieść je po zakończeniu wszystkich oczekiwanych kopii zapasowych i wyboru danych objętych retencją. Przydziel check osobną fazę lub okno, zależnie od rozmiaru repozytorium i szybkości backendu.
Konfiguracja Restic w systemd może utrzymywać kopie zapasowe i prune w osobnych usługach, dzięki czemu harmonogram obserwuje ich kody zakończenia zamiast uruchamiać jedno nieprzejrzyste polecenie.
Jeśli prune regularnie przekracza wyznaczone okno, nie pozwalaj, aby kopie zapasowe po cichu się nawarstwiały. Zmniejsz częstotliwość prune, poszerz okno, zbadaj przepustowość backendu lub podziel repozytoria, gdy ich wymagania operacyjne przestaną się wzajemnie mieścić. Warunkiem rozpoczęcia jest brak aktywnej kopii zapasowej; warunkiem zakończenia — czysty stan konserwacji i zwolniona blokada repozytorium.
Zdefiniuj zależności, ponowienia i alerty
Zdefiniuj zamierzoną kolejność zamiast polegać na odstępach czasowych: jednostki kopii zapasowych zgłaszają zakończenie, forget uruchamia się dopiero po wymaganych kopiach, prune dopiero po wejściu repozytorium w wyłączne okno, a check następuje zgodnie z przyjętymi zasadami konserwacji. Używaj wspólnej zewnętrznej blokady, którą respektują wszystkie odpowiednie jednostki.
Jednostki docelowe systemd mogą wyrażać, że zależności między kopiami zapasowymi a konserwacją muszą być realizowane w określonej kolejności, a nie tylko uruchamiane o różnych porach.
Ustaw ograniczoną liczbę ponowień w przypadku konfliktów blokad i błędów sieci, a następnie wysyłaj alert, gdy termin zostanie przekroczony. Opóźniona kopia zapasowa powinna opóźnić prune; przekroczone okno prune powinno opóźnić następną kopię i powiadomić operatora. Wymuszone zwalnianie blokady i opcje no-lock nie są strategiami ponawiania.
Zweryfikuj dwa pełne cykle i jedno odtworzenie
Obserwuj dwa pełne cykle zamiast uznawać sukces po samym załadowaniu plików timera. Potwierdź, że każde źródło tworzy oczekiwaną migawkę, forget zachowuje zamierzone grupy, prune uruchamia się wyłącznie w swoim oknie, blokady są usuwane po prawidłowym zakończeniu, a alerty rejestrują każde opóźnienie.
Odtwórz pliki z migawki, która przetrwała sekwencję retencji i prune, a nie tylko z najnowszej kopii zapasowej. Dowodzi to, że kompletny harmonogram zachowuje użyteczny punkt odzyskiwania, zamiast jedynie generować statusy zadań oznaczone jako pomyślne.
Harmonogram przechodzi test, gdy dwa cykle kończą się w prawidłowej kolejności, żadne zadanie nie znika po cichu, zachowane migawki odpowiadają podglądowi, a przykładowe odtworzenie jest poprawne. Wycofaj automatyzację konserwacji, zachowując normalne kopie zapasowe, jeśli retencja usuwa niewłaściwą grupę, prune nie może niezawodnie się zakończyć lub konflikty blokad się powtarzają. Dostosowuj częstotliwość na podstawie zmierzonych wyników, a nie przez wyłączanie ochrony repozytorium.
Wsparcie i wskazówki
Więcej do przeczytania

Jak zapobiec blokowaniu zaplanowanych kopii zapasowych przez zadania czyszczenia Restic
Plan zapobiegania problemom we współdzielonych repozytoriach Restic, który oddziela okna tworzenia kopii zapasowych od przycinania oraz zachowuje blokady, ponawianie prób i alerty.

Jak usunąć nieaktualną blokadę Restic bez przerywania aktywnej kopii zapasowej
Najmniej inwazyjny proces odblokowywania Restic, który chroni aktywne kopie zapasowe, usuwa wyłącznie nieaktualny stan i potwierdza możliwość odzyskiwania danych zgodnie ze zwykłym harmonogramem.

Dlaczego kopia zapasowa Restic zatrzymuje się, gdy inny host rozpoczyna usuwanie niepotrzebnych danych?
Szczegółowa diagnoza konfliktu blokad podczas czyszczenia Restic, obejmująca sprawdzanie właściciela blokady, bezpieczne odzyskiwanie, ponowne testowanie stanu wyzwalającego oraz warunki zakończenia.

