Dlaczego token wznowienia ZFS Send przestaje działać po ponownym uruchomieniu urządzenia docelowego?

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 ZFS Send Resume Token Stop Working After the Destination Reboots? - Zima Store Online

Restart systemu po stronie docelowej nie powinien zwykle unieważniać tokenu wznowienia ZFS, chyba że zmienił się zapisany stan odbioru, zbiór danych lub wymagana historia źródłowa.

Token to nieprzezroczysty opis konkretnego przerwanego odbioru, a nie uniwersalna zakładka do dowolnej późniejszej próby replikacji. Jest przypisany do systemu plików lub woluminu docelowego, który zachował częściowy stan dzięki odbiorowi z możliwością wznowienia. Po restarcie zadanie może odczytywać niewłaściwy zbiór danych, zaimportować pulę w inny sposób, wyczyścić częściowy stan, zmodyfikować miejsce docelowe, utracić wymagany migawkowy obraz źródłowy lub wygenerować niezgodny strumień. Przed ponownym uruchomieniem pełnego transferu zweryfikuj token po obu stronach.

Potwierdź, że częściowy stan odbioru przetrwał restart

Po stronie docelowej odczytaj właściwość receive_resume_token z dokładnego systemu plików lub woluminu użytego podczas przerwanego odbioru. Zapisz nazwę puli, ścieżkę zbioru danych, wartość tokenu oraz wykorzystanie przestrzeni przez częściowy stan.

Podręcznik FreeBSD wyjaśnia, że odbiorniki z możliwością wznowienia zachowują częściowy stan i przechowują nieprzezroczysty token w docelowym zbiorze danych do czasu ukończenia transferu lub jawnego porzucenia tego stanu.

Jeśli po restarcie właściwość jest pusta, odbiór nie został zapisany z opcją umożliwiającą wznowienie, częściowy stan został ukończony lub przerwany, odpytywany jest niewłaściwy zbiór danych albo automatyczne czyszczenie go usunęło. Nie używaj ponownie tokenu skopiowanego z wcześniejszego transferu.

Sprawdź, czy token należy do dokładnego docelowego zbioru danych

Sprawdź, czy pula docelowa została zaimportowana pod oczekiwaną nazwą i czy replikacja nadal kieruje się do tej samej ścieżki zbioru danych. Zwróć uwagę na alternatywne katalogi główne, zmienione nazwy pul, zmiany ścieżek nadrzędnych oraz opcje zadania, które dodają lub usuwają elementy ścieżki.

Dokumentacja właściwości ZFS w Ubuntu definiuje receive_resume_token jako właściwość zbioru danych, co oznacza, że token musi zostać odczytany z systemu plików lub woluminu przechowującego ten konkretny zapisany stan.

Nie można bezpiecznie zakładać, że token pobrany z backup/pool/data wznowi odbiór kierowany obecnie do backup/data. Popraw ścieżkę zadania, zanim zmienisz migawkowe obrazy lub usuniesz częściowy odbiór.

Sprawdź, czy miejsce docelowe nie zostało zmodyfikowane lub wycofane

Przeanalizuj polecenia, zaplanowane zadania, oprogramowanie do replikacji, zasady przechowywania migawek oraz działania administratorów od momentu przerwania. Poszukaj wycofania zmian, promocji klonu, zmiany nazwy zbioru danych, przerwania odbioru lub nowego odbioru do tego samego miejsca docelowego.

Klara Systems zauważa, że narzędzia do replikacji zarządzają stanem miejsca docelowego wokół operacji ZFS send i receive, więc zadanie orkiestracji może unieważnić pierwotną ścieżkę odzyskiwania, czyszcząc lub zastępując zapisany stan.

Podczas analizy nie zapisuj zwykłych plików w miejscu docelowym replikacji. Nawet jeśli token nadal istnieje, zmiany w miejscu docelowym mogą zablokować strumień lub wymusić wycofanie zmian, które zniszczy nowsze dane docelowe.

-15% OFF

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

Single board computer zimaboard2

Sprawdź, czy źródło nadal zawiera łańcuch migawek lub zakładek

Określ źródłowy zbiór danych oraz migawkowe obrazy lub zakładki uwzględnione w przerwanym transferze. Porównaj je z bieżącą polityką przechowywania oraz wszelkimi zmianami nazw lub usunięciami migawek od momentu zatrzymania transferu.

Podręcznik FreeBSD dotyczący zfs-send określa, że zfs send -t generuje strumień na podstawie tokenu wznowienia odbioru, wiążąc nowy strumień z przerwanym odbiorem, a nie z dowolnym bieżącym migawkowym obrazem.

Jeśli zasady przechowywania usunęły wymaganą historię źródłową, token nie może odtworzyć danych, które już nie istnieją. Zachowaj pozostały częściowy stan miejsca docelowego, dopóki nie zdecydujesz, czy potrzebna jest inna kopia źródłowa, czy nowy pełny transfer.

Sprawdź funkcje puli i opcje strumienia w obu systemach

Zapisz wersje ZFS, włączone funkcje puli, stan szyfrowania oraz pierwotne opcje strumienia, takie jak transfery raw, compressed, embedded lub large-block. Porównaj je po każdej aktualizacji oprogramowania lub puli.

Dokumentacja Oracle dotycząca replikacji z możliwością wznowienia opisuje wznowienie przerwanego transferu jako skoordynowaną operację wysyłania i odbioru, dlatego zgodność oraz pierwotny kontekst transferu nadal mają znaczenie po restarcie.

Sam restart nie zmienia flag funkcji, ale aktualizacja wykonana podczas przestoju już może. Zanim uznasz, że token jest uszkodzony, odtwórz ręcznie polecenie wznowienia z pełnym wyjściem diagnostycznym.

Zweryfikuj usługi replikacji i SSH po uruchomieniu miejsca docelowego

Potwierdź, że pula docelowa jest zaimportowana, wymagane zaszyfrowane zbiory danych są odblokowane, SSH działa, użytkownik replikacji może wykonywać polecenia ZFS, a zadanie uruchamia się dopiero po przygotowaniu pamięci masowej.

Wytyczne TrueNAS dotyczące replikacji zdalnej wymagają, aby docelowe wymagania SSH i zbiorów danych były dostępne po restarcie; w przeciwnym razie automatyzacja może zakończyć się niepowodzeniem, zanim w ogóle spróbuje użyć zapisanego tokenu.

Przed uruchomieniem wznowionego strumienia przetestuj uwierzytelnianie i zapytanie właściwości tylko do odczytu. Błąd sieci lub uprawnień może wyglądać w dzienniku zadania wysokiego poziomu jak błąd tokenu.

Wznów odbiór raz albo świadomie przerwij częściowy odbiór

Wygeneruj jeden wznowiony strumień wysyłania przy użyciu bieżącego tokenu i przekaż go do odbioru z możliwością wznowienia w tym samym miejscu docelowym. Zapisz pełne dane wyjściowe błędu i nie uruchamiaj równoległych zadań replikacji.

Przewodnik migracji danych NAS ZimaSpace przedstawia powiązaną zasadę bezpieczeństwa: zachowaj źródło i ścieżkę wycofania zmian do czasu zweryfikowania miejsca docelowego.

Jeśli token jest bezużyteczny, a częściowy stan nie ma już wartości, przerwij go za pomocą obsługiwanego polecenia przerwania odbioru dopiero po potwierdzeniu, że można wygenerować nowy pełny lub przyrostowy transfer. Przerwanie zwalnia zapisany częściowy stan i nie można go cofnąć.

Najczęściej zadawane pytania

Czy restart miejsca docelowego zawsze unieważnia token wznowienia ZFS?

Nie. Zapisany częściowy odbiór został zaprojektowany tak, aby przetrwać przerwanie, w tym nieprawidłowe wyłączenie systemu. Niepowodzenie po restarcie zwykle oznacza, że zadanie odczytuje inny zbiór danych, częściowy stan został wyczyszczony, zmieniła się wymagana historia źródłowa albo brakuje zależności uruchamianych podczas startu.

Czy można wygenerować nowy token wznowienia wyłącznie ze źródła?

Nie. Nieprzezroczysty token pochodzi z zapisanego częściowego stanu odbioru w docelowym zbiorze danych. Źródło używa tego tokenu do wygenerowania strumienia kontynuacji, ale samo nie może odtworzyć usuniętego stanu miejsca docelowego.

Kiedy należy przerwać częściowy odbiór?

Przerwij go dopiero wtedy, gdy ścieżka wznowienia okaże się nieużyteczna, źródło będzie mogło wygenerować zastępczy transfer, a częściowy stan miejsca docelowego nie będzie już potrzebny do odzyskiwania danych. Przed jego usunięciem zachowaj dzienniki i dostępne migawkowe obrazy.