Warum überspringt die Snapshot-Replikation ein verschlüsseltes untergeordnetes Dataset, während andere übertragen werden?

Die Replikation kann ein verschlüsseltes untergeordnetes Dataset überspringen, wenn sich dessen Aufgabenumfang, Snapshot-Satz, Verschlüsselungsstamm, Sendemodus, Berechtigungen oder Zielrichtlinie von denen der Geschwister-Datasets unterscheidet.

Verschlüsselung allein verhindert die Replikation von ZFS-Snapshots nicht automatisch, und ein unverschlüsselter Rohdaten-Send kann auch funktionieren, wenn der Schlüssel nicht geladen ist. Das übersprungene untergeordnete Dataset hat häufig einen separaten Verschlüsselungsstamm, besitzt nicht den vom rekursiven Auftrag ausgewählten Snapshot-Namen, ist vom Auftrag ausgeschlossen, erfordert eine Berechtigung zum Senden von Rohdaten oder kann unter dem aktuellen Verschlüsselungslayout des Ziels nicht empfangen werden. Vergleichen Sie das untergeordnete Dataset Eigenschaft für Eigenschaft mit einem funktionierenden Geschwister-Dataset.

Bestätigen Sie, dass das untergeordnete Dataset im Replikationsumfang enthalten ist

Notieren Sie das ausgewählte Quelldataset, die rekursive Einstellung, ausgeschlossene untergeordnete Datasets, Namensfilter, den Zielpfad und die genaue Protokollmeldung zum übersprungenen Dataset.

Die Dokumentation zur Remote-Replikation von TrueNAS verlangt, dass der Quell- und Zielumfang ausdrücklich festgelegt wird. Daher kann ein untergeordnetes Dataset ausgelassen werden, während Geschwister-Datasets übertragen werden.

Wenn das untergeordnete Dataset nie im Aufgabenplan erscheint, korrigieren Sie Auswahl oder Ausschlüsse, bevor Sie die Verschlüsselung testen.

Überprüfen Sie, ob das untergeordnete Dataset den vom Auftrag benötigten Snapshot besitzt

Listen Sie Snapshots rekursiv auf und vergleichen Sie das übersprungene Dataset mit einem funktionierenden Geschwister-Dataset, einschließlich Snapshot-Name, Erstellungszeit, Haltezuständen und inkrementeller Basis.

Das FreeBSD-Handbuch beschreibt Snapshots als datensatzspezifische Zustände. Daher beweist ein Snapshot-Name des übergeordneten Datasets nicht, dass jedes unabhängige untergeordnete Dataset den erforderlichen Snapshot besitzt.

Erstellen oder synchronisieren Sie Snapshots über den normalen Auftrag. Eine nicht übereinstimmende inkrementelle Kette kann eine neue Basis erfordern.

Vergleichen Sie Verschlüsselungsstamm, Schlüsselstatus und Schlüsselspeicherort

Notieren Sie für das übersprungene Dataset und ein funktionierendes verschlüsseltes Geschwister-Dataset die Werte für encryption, encryptionroot, keystatus, keyformat und keylocation.

Die Referenz zu den ZFS-Eigenschaften von Ubuntu definiert Verschlüsselungsstamm- und Schlüsseleigenschaften und zeigt, ob das untergeordnete Dataset den Schlüssel des übergeordneten Datasets übernimmt oder einen eigenen Stamm besitzt.

Ein nicht geladener Schlüssel verhindert nicht jedes Senden von Rohdaten, blockiert jedoch Arbeitsabläufe, die Zugriff auf Klartext benötigen.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Prüfen Sie, ob der Auftrag das Senden verschlüsselter Rohdaten erfordert

Vergleichen Sie die Optionen für Rohdaten, Nicht-Rohdaten, rekursives Senden, Eigenschaftserhalt, Komprimierung und inkrementelles Senden für funktionierende und übersprungene Datasets.

Oracle dokumentiert, dass die verschlüsselte Rohdatenreplikation spezifische Anforderungen an Quelle, Ziel und Verschlüsselungskontext stellt.

Wenn das untergeordnete Dataset zuvor ohne Rohdaten empfangen wurde und der Auftrag auf inkrementelles Senden von Rohdaten umgestellt wird, kann der Verlauf am Ziel inkompatibel sein.

Überprüfen Sie die Berechtigungen zum Senden, Senden von Rohdaten, Erstellen von Snapshots und Verwenden von Schlüsseln

Ermitteln Sie den Replikationsbenutzer und vergleichen Sie die delegierten Berechtigungen auf dem übergeordneten Dataset, dem übersprungenen untergeordneten Dataset und einem funktionierenden Geschwister-Dataset.

OpenZFS dokumentiert delegierte Administrationsberechtigungen und erklärt, warum sich der Zugriff bei einem untergeordneten Dataset mit eigenem Verschlüsselungsstamm unterscheiden kann.

Gewähren Sie nur die fehlende Berechtigung. Umfassender Administratorzugriff verschleiert die tatsächliche Grenze und erhöht das Risiko.

Überprüfen Sie die Verschlüsselungs- und Vererbungsregeln am Ziel

Vergleichen Sie den Verschlüsselungsstatus des übergeordneten Ziels, prüfen Sie, ob das untergeordnete Ziel bereits vorhanden ist, und vergleichen Sie dessen Verschlüsselungsstamm, geerbte Eigenschaften und Empfangsverhalten.

Das zfs-receive-Handbuch von FreeBSD erklärt, dass Rohdatenströme unverändert empfangen werden, während Nicht-Rohdatenströme einer anderen Verschlüsselungsvererbung folgen können.

Ein bereits vorhandenes, inkompatibles untergeordnetes Dataset am Ziel kann nur dieses Dataset ablehnen, während die vom Auftrag erstellten Geschwister-Datasets erfolgreich übertragen werden.

Führen Sie einen Test mit einem einzelnen Dataset durch und bewahren Sie die funktionierende Replikation

Pausieren Sie den Zeitplan, erstellen Sie eine Probelauf- oder ausführliche Sende-Schätzung für das übersprungene Dataset und vergleichen Sie sie mit einem funktionierenden Geschwister-Dataset.

Der ZimaSpace-Artikel zu Warnzeichen für verschlüsselte Wiederherstellungsschlüssel liefert die ergänzende Sicherheitsregel: Verifizieren Sie die Schlüsselabhängigkeiten, bevor Sie die einzige verschlüsselte Kopie löschen.

Das Problem ist behoben, wenn das untergeordnete Dataset im Umfang enthalten ist, die erforderlichen Snapshots besitzt, einen kompatiblen Sendemodus verwendet, die Berechtigungen erfüllt und unter dem vorgesehenen Verschlüsselungslayout empfangen wird.