Lista kontrolna weryfikacji elementu nadrzędnego Btrfs Send przed czyszczeniem migawek

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.

Nie usuwaj rodzica operacji Btrfs send tylko dlatego, że wygląda na stary. Najpierw upewnij się, że nowsza migawka tylko do odczytu istnieje po obu stronach i może posłużyć w następnym cyklu przyrostowym.

W domowym NAS-ie migawki źródłowe i docelowe często mają podobne nazwy, choć pełnią różne role w replikacji. Czyszczenie staje się ryzykowne, gdy zadanie rotacji uwzględnia tylko wiek, a nie to, która para stanowi podstawę następnej operacji send. Zacznij od spisu tylko do odczytu, wskaż ostatnią pomyślną parę źródło–cel, przetestuj nowszą migawkę podrzędną względem niej i zachowaj poprzednią migawkę docelową do czasu zakończenia kolejnej operacji incremental receive.

Utwórz spis bieżącej pary nadrzędnej w obu systemach

Wyświetl podwolumin źródłowy, wszystkie migawki send tylko do odczytu oraz wszystkie odebrane migawki docelowe. Zapisz ścieżkę, czas utworzenia, stan tylko do odczytu, identyfikator podwoluminu, UUID, relację nadrzędną oraz — jeśli są dostępne — informacje o tożsamości odebranej migawki. Połącz ostatnią pomyślną migawkę źródłową z kopią, która faktycznie została odebrana, a nie tylko z katalogiem o podobnej nazwie.

Działająca sekwencja Btrfs send i receive zachowuje poprzednią migawkę w obu systemach, zanim użyje jej jako rodzica następnego strumienia przyrostowego.

Jeśli para jest jednoznacznie obecna i tylko do odczytu, oznacz ją jako chronioną. Jeśli zgadzają się tylko nazwy, sprawdź relację odebrania oraz dziennik replikacji, zanim przejdziesz dalej. Jeśli brakuje kopii docelowej, przerwij czyszczenie i zaplanuj nowe pełne wysłanie albo użycie innej zweryfikowanej podstawy; usunięcie migawki źródłowej nie naprawi brakującej historii odbiorcy.

Udowodnij, że nowsza migawka może zostać następnym rodzicem

Po zapisaniu spisu utwórz następną migawkę źródłową tylko do odczytu. Użyj chronionej migawki źródłowej jako jawnie wskazanego rodzica i wyślij nową migawkę podrzędną do zamierzonego miejsca docelowego lub ścieżki tymczasowej. Zapisz kod zakończenia i dziennik, a następnie porównaj próbkę zmienionych i niezmienionych plików w odebranej migawce.

Skrypty replikacji przyrostowej powinny jasno pokazywać zależność. Praktyczny proces rotacji migawek działa tylko wtedy, gdy migawki oczekiwane przez logikę send pozostają na swoim miejscu.

Przenieś nową parę na listę kandydatów do czyszczenia dopiero wtedy, gdy odbieranie zakończy się powodzeniem, a migawka docelowa będzie możliwa do odczytu. Błąd braku rodzica, zapisywalna migawka źródłowa, niewłaściwy zbiór danych lub strumień nieoczekiwanie równoważny pełnej kopii oznaczają nieudany test. Pozostaw starą parę bez zmian, dopóki nie poprawisz ścieżki lub nie odbudujesz podstawy.

Wykonuj czyszczenie dopiero po przesunięciu roli rodzica

Zaktualizuj rekord przechowywania, zanim cokolwiek usuniesz. Oznacz nowo zweryfikowane migawki źródłową i docelową jako aktywną parę, zachowaj bezpośrednio poprzednią parę jako krótkoterminowy mechanizm awaryjny i wyświetl podgląd starszych migawek, które zadanie czyszczenia usunęłoby. Podgląd powinien zawierać wyłącznie przodków, które nie są już potrzebne do następnej operacji send ani planu odtwarzania.

Zmiana pliku może zostać przeniesiona do nowszej migawki i wysłana z istniejącej podstawy, dlatego przyszła historia przyrostowa zależy od zachowanych relacji między migawkami, a nie od edytowania starej migawki tylko do odczytu.

Anuluj czyszczenie, jeśli na liście usuwania znajduje się aktywny rodzic, para awaryjna, najnowsza odebrana migawka lub niezweryfikowana osierocona migawka. Usuwaj migawki małymi grupami i po każdej grupie ponownie wyświetl ich spis w obu systemach. Nie pozwalaj, aby niezależne zadania rotacji źródłowej i docelowej przesuwały się naprzód bez współdzielenia tego samego rekordu chronionej pary.

Wykonaj kolejny cykl przyrostowy, zanim wycofasz mechanizm awaryjny

Po czyszczeniu wprowadź jedną kontrolowaną zmianę w pliku i utwórz nową migawkę tylko do odczytu. Uruchom kolejne przyrostowe wysyłanie z nowo awansowanego rodzica. Ten drugi cykl potwierdza, że rekord czyszczenia, skrypt i stan miejsca docelowego są zgodne; samo pierwsze pomyślne wysłanie nie sprawdziło środowiska po czyszczeniu.

Jeśli nie można usunąć migawki, ponieważ jest nadal używana, oddziel logikę przechowywania od aktywnej ścieżki Btrfs send, zanim uznasz mapę rodziców za nieprawidłową.

Lista kontrolna jest zaliczona, gdy druga migawka podrzędna zostanie pomyślnie odebrana, oczekiwane pliki będą obecne, aktywna para pozostanie tylko do odczytu, a następne zaplanowane uruchomienie wybierze ją automatycznie. Wycofaj mechanizm awaryjny dopiero po uzyskaniu tego wyniku. Zatrzymaj proces i przywróć poprzednią parę do stanu chronionego, jeśli następne wysyłanie zgłosi brak rodzica, będzie wskazywać niewłaściwy podwolumin lub zaproponuje nieoczekiwany pełny transfer.

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.