Jak sprawdzić, czy replikację ZFS można wznowić po przerwaniu transferu

Tak, jeśli strona odbierająca zachowuje prawidłowy token wznowienia, a migawki źródłowe wymagane przez ten token nadal istnieją.

Decyzja ma znaczenie, gdy surowe lub przyrostowe polecenie zfs send zostanie przerwane przez awarię sieci lub miejsca docelowego. Dwa konkurencyjne stany to prawidłowy token wznowienia odbierania oraz brak tokenu lub usunięta migawka źródłowa. Zacznij od zapisanej konfiguracji i danych tymczasowych, obserwuj jednorazowo tylko jedną gałąź i przerwij, jeśli test zwiększa ryzyko utraty danych, problemów z uprawnieniami lub dostępnością.

Określ warunki leżące u podstaw decyzji dotyczącej wznawialnej replikacji ZFS

Zapisz środowisko przed wprowadzeniem jakichkolwiek zmian: wersje oprogramowania i oprogramowania układowego, tożsamości urządzeń, ścieżkę montowania lub sieciową, wolne miejsce, uprawnienia oraz obserwowany objaw. Wartość bazowa musi zachować wystarczająco dużo szczegółów, aby odtworzyć sytuację, w której surowe lub przyrostowe polecenie zfs send zostaje przerwane przez awarię sieci lub miejsca docelowego.

Pierwszym kandydatem jest prawidłowy token wznowienia odbierania. Drugim jest brak tokenu lub usunięta migawka źródłowa. Bieżące wznawialne zfs send określa mechanizm lub granicę polecenia używaną w teście; nie zastępuje obserwacji z tego konkretnego serwera domowego.

Zapisz warunek akceptacji i warunek przerwania przed uruchomieniem testu rozstrzygającego. Wynik pozytywny musi zmienić dowody przewidywane przez jedną gałąź, pozostawiając niepowiązane usługi bez zmian; wynik negatywny musi przywrócić system do zapisanego stanu, zamiast uruchamiać ciąg spekulatywnych napraw.

Przetestuj twierdzenie bez obniżania pierwotnego wymagania

Użyj następującego testu rozstrzygającego: przerwij replikację danych tymczasowych, odczytaj token, wygeneruj wznowiony strumień wysyłania i porównaj końcową migawkę miejsca docelowego. Zachowaj stałe obciążenie, klienta, ścieżkę, zestaw plików i czas, aby wynik można było przypisać zmienionej zmiennej.

Użyj wysyłania i odbierania ZFS, aby wybrać pole, które rzeczywiście może rozdzielić te gałęzie, a następnie zarejestruj jego znacznik czasu, kod wyjścia, tekst błędu, tożsamość urządzenia lub migawki, opóźnienie, liczbę przesłanych bajtów, uprawnienia oraz stan odzyskiwania. Prawidłowe zakończenie polecenia nie wystarczy, gdy testowane twierdzenie dotyczy tożsamości, trwałości lub stanu aplikacji.

Powtórz test po restarcie, ponownym połączeniu, ponownym zamontowaniu lub opróżnieniu pamięci podręcznej, jeśli takie zdarzenie jest częścią pierwotnego warunku. Jeśli pierwszy przebieg jest destrukcyjny lub środowiska nie można przywrócić, przerwij i odtwórz test na kopii tymczasowej.

token=$(zfs get -H -o value receive_resume_token pool/dst)
zfs send -t "$token" | ssh nas zfs receive pool/dst

Interpretuj wyniki pozytywne, negatywne i wyjątkowe

WYNIK POZYTYWNY: strumień wznowienia kończy się pomyślnie, a migawki źródłowa i docelowa mają oczekiwaną wspólną linię pochodzenia GUID. Zapisz dokładną wersję, tożsamość i obciążenie, przy których test zakończył się pomyślnie, aby wniosek pozostał warunkowy, a nie stał się twierdzeniem uniwersalnym.

WYNIK NEGATYWNY: nie istnieje token, miejsce docelowe zostało wycofane lub wymagane migawki źródłowe zostały usunięte. Wynik negatywny nie dowodzi automatycznie przeciwnej gałęzi, gdy na obie mogą wpływać sieć, pamięć, uprawnienia lub spójność źródła; przed eskalacją odizoluj te wspólne zależności.

WYNIK WYJĄTKOWY LUB NIEJEDNOZNACZNY: przerwij częściowe odbieranie dopiero po ustaleniu, że koszt ponownego uruchomienia jest akceptowalny. Zachowaj dzienniki i nie uruchamiaj poleceń naprawczych, czyszczących, usuwających, partycjonujących ani rekurencyjnie zmieniających właściciela, dopóki nie będzie dostępna kopia możliwa do odzyskania.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Potwierdź decyzję przy pierwotnym obciążeniu

Zastosuj działanie dopasowane do zaobserwowanej gałęzi, a następnie odtwórz pierwotny warunek, zamiast używać uproszczonego zamiennika. Decyzja obowiązuje tylko wtedy, gdy strumień wznowienia kończy się pomyślnie, a migawki źródłowa i docelowa mają oczekiwaną wspólną linię pochodzenia GUID przez dwa cykle lub podczas odpowiedniego ponownego uruchomienia, uśpienia, przerwania albo przejścia obciążenia.

Użyj niezmiennych okien kopii zapasowych, aby sprawdzić najbliższy zależny przepływ pracy, ale zachowaj niezmieniony pierwotny wyzwalacz. Niepowiązane zestawy danych, udziały, kontenery, użytkownicy i punkty odzyskiwania muszą zachować wcześniejszy dostęp i czasy działania.

Granica przerwania jest jednoznaczna: jeśli nie istnieje token, miejsce docelowe zostało wycofane lub wymagane migawki źródłowe zostały usunięte, wróć do ostatniej zweryfikowanej konfiguracji, zachowaj dowody i przejdź do głębszego testu platformy lub sprzętu tylko wtedy, gdy gałąź można powtórzyć.

Po uzyskaniu docelowego wyniku porównaj go z układem repozytorium lokalnego, aby upewnić się, że poprawka nie przenosi ryzyka do sąsiedniej usługi. Pomyślny test docelowy z nowym błędem kopii zapasowej, tożsamości, limitu czasu lub dostępności nadal oznacza nieudaną zmianę.

FAQ

W przypadku wznawialnej replikacji ZFS pozostałe pytania zwykle dotyczą tego, czy każde przerwane odbieranie tworzy token, czy po przerwaniu można usunąć stare migawki źródłowe oraz jak zweryfikować końcową replikę. Poniższe odpowiedzi oddzielają te przypadki brzegowe od głównej decyzji.

Granica akceptacji pozostaje niezmieniona: strumień wznowienia kończy się pomyślnie, a migawki źródłowa i docelowa mają oczekiwaną wspólną linię pochodzenia GUID. Jeśli kolejny warunek zmieni system plików, tożsamość, ścieżkę sieciową lub wersję aplikacji, powtórz tylko test rozstrzygający, którego dotyczy ta zmiana.

Przerwij rozszerzanie eksperymentu, gdy nie istnieje token, miejsce docelowe zostało wycofane lub wymagane migawki źródłowe zostały usunięte. W takim przypadku przerwij częściowe odbieranie dopiero po ustaleniu, że koszt ponownego uruchomienia jest akceptowalny; zachowaj dowody przed eskalacją do właściciela platformy, pamięci masowej lub sprzętu.

Czy każde przerwane odbieranie tworzy token?

Nie. Odbieranie musi używać trybu wznawialnego i zakończyć się w stanie zachowującym token.

Czy po przerwaniu można usunąć stare migawki źródłowe?

Nie, dopóki wznowiony strumień nadal od nich zależy i miejsce docelowe nie zostało zweryfikowane.

Jak zweryfikować końcową replikę?

Porównaj linię pochodzenia GUID migawek, właściwości, oczekiwane pliki oraz próbkę przywracania - nie tylko kod wyjścia polecenia.

W przypadku wznawialnej replikacji ZFS praktyczna odpowiedź pozostaje warunkowa: strumień wznowienia kończy się pomyślnie, a migawki źródłowa i docelowa mają oczekiwaną wspólną linię pochodzenia GUID. Gdy nie istnieje token, miejsce docelowe zostało wycofane lub wymagane migawki źródłowe zostały usunięte, przerwij częściowe odbieranie dopiero po ustaleniu, że koszt ponownego uruchomienia jest akceptowalny; częściowy sukces, który nie wytrzymuje pierwotnego obciążenia, nie oznacza zgodności.