Warum funktioniert ein ZFS-Sende-Fortsetzungstoken nach einem Neustart des Zielsystems nicht mehr?

Ein Neustart des Zielsystems sollte ein ZFS-Fortsetzungstoken normalerweise nicht ungültig machen, es sei denn, der gespeicherte Empfangszustand, das Dataset oder die erforderliche Quellhistorie wurde geändert.

Das Token ist eine undurchsichtige Beschreibung eines bestimmten unterbrochenen Empfangsvorgangs und kein wiederverwendbares Lesezeichen für einen späteren Replikationsversuch. Es gehört zum Zieldateisystem oder -volume, das den Teilzustand eines fortsetzbaren Empfangs bewahrt hat. Nach einem Neustart kann ein Task das falsche Dataset lesen, den Pool anders importieren, den Teilzustand löschen, das Ziel ändern, einen erforderlichen Quell-Snapshot verlieren oder einen inkompatiblen Stream erzeugen. Überprüfen Sie das Token an beiden Enden, bevor Sie eine vollständige Übertragung neu starten.

Bestätigen Sie, dass der Teilzustand des Empfangs den Neustart überstanden hat

Lesen Sie auf dem Ziel die Eigenschaft receive_resume_token des exakt für den unterbrochenen Empfang verwendeten Dateisystems oder Volumes aus. Notieren Sie den Poolnamen, den Dataset-Pfad, den Tokenwert und den Speicherverbrauch des Teilzustands.

Das FreeBSD-Handbuch erklärt, dass fortsetzbare Empfangsvorgänge den Teilzustand bewahren und ein undurchsichtiges Token im empfangenden Dataset speichern, bis die Übertragung abgeschlossen oder der Zustand ausdrücklich aufgegeben wird.

Ist die Eigenschaft nach dem Neustart leer, wurde der Empfang nicht mit der Option für fortsetzbare Übertragungen gespeichert, der Teilzustand wurde abgeschlossen oder abgebrochen, das falsche Dataset wird abgefragt oder eine automatische Bereinigung hat ihn entfernt. Verwenden Sie kein aus einer früheren Übertragung kopiertes Token erneut.

Überprüfen Sie, ob das Token zum exakt richtigen Zieldataset gehört

Prüfen Sie, ob der Zielpool unter dem erwarteten Namen importiert wurde und ob die Replikation weiterhin dasselbe Dataset-Ziel verwendet. Achten Sie auf alternative Root-Pfade, umbenannte Pools, Änderungen an übergeordneten Pfaden sowie Task-Optionen, die Pfadbestandteile hinzufügen oder entfernen.

Ubuntus Referenz zu ZFS-Eigenschaften definiert receive_resume_token als Dataset-Eigenschaft. Daher muss das Token aus dem Dateisystem oder Volume ausgelesen werden, das genau diesen gespeicherten Zustand enthält.

Es kann nicht sicher angenommen werden, dass ein aus backup/pool/data abgerufenes Token einen Empfang fortsetzen kann, der jetzt auf backup/data zielt. Korrigieren Sie den Task-Pfad, bevor Sie Snapshots ändern oder den Teilzustand des Empfangs zerstören.

Prüfen Sie, ob das Ziel geändert oder zurückgesetzt wurde

Untersuchen Sie Befehle, geplante Tasks, Replikationssoftware, die Snapshot-Aufbewahrung und Administratoraktivitäten seit der Unterbrechung. Suchen Sie nach Zurücksetzungen, der Aktivierung von Klonen, Dataset-Umbenennungen, abgebrochenen Empfangsvorgängen oder einem neuen Empfang in dasselbe Ziel.

Klara Systems weist darauf hin, dass Replikationstools den Zielzustand verwalten und ein Orchestrierungs-Task den ursprünglichen Wiederherstellungspfad ungültig machen kann, indem er den gespeicherten Zustand bereinigt oder ersetzt.

Schreiben Sie während der Untersuchung keine normalen Dateien in ein Replikationsziel. Selbst wenn das Token noch vorhanden ist, können Änderungen am Ziel den Stream blockieren oder einen Rollback erzwingen, der neuere Zieldaten zerstört.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Überprüfen Sie, ob die Quelle die Snapshot- oder Bookmark-Kette noch besitzt

Ermitteln Sie das Quelldataset sowie die Snapshots oder Bookmarks, die in der unterbrochenen Übertragung enthalten waren. Vergleichen Sie sie mit der aktuellen Aufbewahrung sowie mit seit dem Abbruch umbenannten oder gelöschten Snapshots.

Das FreeBSD-zfs-send-Handbuch legt fest, dass zfs send -t anhand des Empfangs-Fortsetzungstokens einen Stream erzeugt. Dadurch wird der neue Stream an den unterbrochenen Empfang und nicht an einen beliebigen aktuellen Snapshot gebunden.

Wenn die Aufbewahrungsrichtlinie die erforderliche Quellhistorie gelöscht hat, kann das Token keine Daten rekonstruieren, die nicht mehr vorhanden sind. Bewahren Sie den verbleibenden Teilzustand auf dem Ziel, bis Sie entschieden haben, ob eine weitere Quellkopie oder eine neue vollständige Übertragung erforderlich ist.

Überprüfen Sie Pool-Funktionen und Stream-Optionen auf beiden Systemen

Notieren Sie die ZFS-Versionen, aktivierten Pool-Funktionen, den Verschlüsselungszustand und die ursprünglichen Stream-Optionen wie Raw-, komprimierte, eingebettete oder Large-Block-Übertragungen. Vergleichen Sie diese Werte nach jedem Software- oder Pool-Upgrade.

Oracles Dokumentation zur fortsetzbaren Replikation beschreibt das Fortsetzen einer unterbrochenen Übertragung als koordinierten Sende- und Empfangsvorgang. Daher bleiben Kompatibilität und der ursprüngliche Übertragungskontext auch nach einem Neustart wichtig.

Ein Neustart allein ändert keine Feature-Flags, ein während des Ausfalls durchgeführtes Upgrade jedoch möglicherweise schon. Führen Sie den Fortsetzungsbefehl zunächst manuell mit ausführlicher Ausgabe aus, bevor Sie annehmen, dass das Token selbst beschädigt ist.

Überprüfen Sie Replikationsdienste und SSH nach dem Start des Zielsystems

Bestätigen Sie, dass der Zielpool importiert wurde, erforderliche verschlüsselte Datasets entsperrt sind, SSH läuft, der Replikationsbenutzer ZFS-Befehle ausführen kann und der Task erst startet, nachdem der Speicher bereit ist.

Die Anleitung zur Remote-Replikation von TrueNAS setzt voraus, dass SSH- und Dataset-Voraussetzungen auf dem Ziel nach einem Neustart verfügbar sind. Andernfalls kann die Automatisierung fehlschlagen, bevor sie das gespeicherte Token überhaupt verwendet.

Testen Sie die Authentifizierung und eine schreibgeschützte Abfrage der Eigenschaften, bevor Sie den fortgesetzten Stream starten. Ein Netzwerk- oder Berechtigungsfehler kann in einem Protokoll auf hoher Task-Ebene wie ein Token-Fehler aussehen.

Setzen Sie den Teilzustand des Empfangs einmal fort oder brechen Sie ihn bewusst ab

Erzeugen Sie anhand des aktuellen Tokens einen einzigen fortgesetzten Sendestream und übergeben Sie ihn an einen fortsetzbaren Empfang auf demselben Ziel. Speichern Sie die vollständige Fehlerausgabe und vermeiden Sie parallel gestartete Replikationstasks.

Der NAS-Datenmigrationsleitfaden von ZimaSpace formuliert die entsprechende Sicherheitsregel: Bewahren Sie Quelle und Rollback-Pfad auf, bis das Ziel überprüft wurde.

Wenn das Token unbrauchbar ist und der Teilzustand keinen Wert mehr hat, brechen Sie ihn erst dann mit dem unterstützten Befehl zum Abbrechen des Empfangs ab, wenn bestätigt wurde, dass eine neue vollständige oder inkrementelle Übertragung erzeugt werden kann. Durch das Abbrechen wird der gespeicherte Teilzustand freigegeben und der Vorgang kann nicht rückgängig gemacht werden.

Häufig gestellte Fragen

Macht ein Neustart des Zielsystems ein ZFS-Fortsetzungstoken immer ungültig?

Nein. Ein gespeicherter Teilzustand eines Empfangs ist dafür ausgelegt, Unterbrechungen einschließlich eines unsauberen Herunterfahrens zu überstehen. Ein Fehler nach dem Neustart bedeutet meist, dass der Task ein anderes Dataset liest, der Teilzustand gelöscht wurde, sich die erforderliche Quellhistorie geändert hat oder Startabhängigkeiten fehlen.

Kann ein neues Fortsetzungstoken allein auf der Quelle erzeugt werden?

Nein. Das undurchsichtige Token stammt aus dem gespeicherten Teilzustand des Empfangs im Zieldataset. Die Quelle verwendet dieses Token, um einen Fortsetzungsstream zu erzeugen, kann jedoch einen gelöschten Zielzustand nicht selbst wiederherstellen.

Wann sollte der Teilzustand des Empfangs abgebrochen werden?

Brechen Sie ihn nur ab, wenn sich der Fortsetzungspfad nachweislich nicht verwenden lässt, die Quelle eine Ersatzübertragung erzeugen kann und der Teilzustand auf dem Ziel für die Wiederherstellung nicht mehr benötigt wird. Sichern Sie Protokolle und verfügbare Snapshots, bevor Sie ihn entfernen.