Führen Sie eine erneute Basisübertragung durch, wenn Sie keine gültige gemeinsame Basis nachweisen können oder die Reparatur der Kette einen nicht verifizierten Rollback des Ziels erfordern würde. Bewahren Sie zuerst die letzte lesbare Replik auf.
Bei einem Home-NAS besteht die verlockende Abkürzung darin, das nächste inkrementelle Senden zu erzwingen, bis es funktioniert. Dadurch können ein fehlender übergeordneter Snapshot, ein abweichendes Ziel oder ein Empfangsziel verborgen werden, das nicht mehr das Dataset ist, für das Sie es halten. Beginnen Sie damit, beide Seiten zu inventarisieren, ohne eine von ihnen zu verändern, weisen Sie nach, ob noch eine gemeinsame Basis vorhanden ist, und verwenden Sie eine gestaffelte vollständige Basisübertragung, wenn die Belege keine sichere inkrementelle Fortsetzung unterstützen.
Weisen Sie nach, dass beide Seiten noch dieselbe Basis gemeinsam haben
Beginnen Sie mit einer schreibgeschützten Bestandsaufnahme des Quelldatasets, des Zieldatasets, der Snapshots, der Lesezeichen und aller Zustände zum Fortsetzen eines Empfangs. Vergleichen Sie mehr als nur einen passenden Snapshot-Namen: Bestätigen Sie, dass die mögliche Basis zu den vorgesehenen Datasets gehört und dieselbe Replikationshistorie darstellt. Speichern Sie die Auflistungen vor der Bereinigung, damit Sie erklären können, warum die nächste Maßnahme gewählt wurde.
Inkrementelle ZFS-Replikation hängt davon ab, dass beim Empfänger bereits eine Basis vorhanden ist. Eine praktische Snapshot-Replikationssequenz bewahrt die gemeinsame Historie daher bewusst, statt davon auszugehen, dass identische Bezeichnungen die Kontinuität beweisen.
Wenn auf beiden Seiten eine verifizierte Basis vorhanden ist, fahren Sie mit einem nicht destruktiven inkrementellen Test fort. Wenn der Name zwar vorhanden ist, sich aber Identität oder Dataset-Pfad unterscheiden, betrachten Sie die Kette als nicht nachgewiesen. Wenn keine gemeinsame Basis mehr vorhanden ist, löschen Sie keine weiteren Snapshots und erzwingen Sie kein Zurücksetzen des Ziels; die Entscheidung geht bereits in Richtung einer gestaffelten erneuten Basisübertragung.
Testen Sie den inkrementellen Plan, ohne die Replik zu verändern
Erstellen Sie den geplanten Sendevorgang mit der verifizierten Basis und dem neuesten Ziel, leiten Sie ihn aber noch nicht in das aktive Ziel weiter. Verwenden Sie einen Probelauf, eine ausführliche Schätzung oder den Vorschaumodus des Replikationswerkzeugs. Bestätigen Sie Quellpfad, Zielpfad, Basis-Snapshot, Ziel-Snapshot, Rekursionsoptionen und die erwartete Stream-Größe, bevor ein Empfang Daten verändern kann.
Ein Scheduler, der keinen gemeinsamen Basis-Snapshot meldet, verweigert eine unsichere Vermutung und fordert nicht einfach nur zu einem erneuten Versuch auf. Wiederholte Versuche stellen keine gelöschte gemeinsame Historie wieder her.
Ein Delta-großer Stream von der exakten Basis zum exakten Ziel spricht für eine Reparatur der Kette. Ein Stream, der beinahe der vollständigen Dataset-Größe entspricht, ein unerwartetes Dataset oder jede erforderliche erzwungene Zurücksetzung bedeutet, dass die Vorschau fehlgeschlagen ist. Halten Sie dort an und bewahren Sie die aktuelle Replik; das Ändern von Optionen, bis der Befehl funktioniert, ist keine Verifizierung.
Wählen Sie eine Reparatur nur, wenn Historie und Zielzustand übereinstimmen
Reparieren Sie den inkrementellen Pfad nur, wenn die gemeinsame Basis verifiziert ist, das Ziel keine unabhängige Arbeitskopie geworden ist und die Vorschau das erwartete Delta vorschlägt. Lassen Sie das Ziel während des Reparaturzeitraums schreibgeschützt. Senden Sie zuerst an ein neues untergeordnetes Dataset oder ein Staging-Ziel, sofern das Werkzeug dies zulässt, und vergleichen Sie die Ergebnisse, bevor Sie es übernehmen.
Führen Sie eine erneute Basisübertragung durch, wenn keine gültige Basis vorhanden ist, das Ziel abgewichen ist, das erforderliche Zurücksetzen Snapshots löschen würde, die Sie noch benötigen, oder der Aufwand zum Nachweis der Kette die kontrollierten Kosten einer neuen vollständigen Übertragung übersteigt. Erörterungen zur Abstammung inkrementeller Snapshots bestätigen, dass Zwischenbezeichnungen weniger wichtig sind als der Erhalt eines nutzbaren gemeinsamen Punkts.
Löschen Sie das alte Ziel nicht, um Platz zu schaffen, es sei denn, eine andere verifizierte Kopie ist vorhanden. Bei einer sichereren erneuten Basisübertragung wird in ein separates Dataset oder einen separaten Pool geschrieben, die neue Kopie verifiziert und die fehlerhafte Kette erst danach außer Betrieb genommen. Wenn nicht genügend Kapazität für beide vorhanden ist, halten Sie an und beschaffen Sie vorübergehend Speicherplatz, statt die letzte lesbare Replik zum Versuch zu machen.
Validieren Sie die neue Kette über zwei Replikationszyklen hinweg
Ein erfolgreicher vollständiger Empfang beweist nur, dass ein Stream eingetroffen ist. Erstellen Sie eine kleine Testdatei oder ändern Sie eine Eigenschaft auf der Quelle, erstellen Sie den nächsten planmäßigen Snapshot und führen Sie einen zweiten inkrementellen Zyklus mit der neuen gemeinsamen Basis durch. Vergleichen Sie nach beiden Durchläufen Dataset-Eigenschaften, Snapshot-Listen, eine Auswahl von Dateien und das Replikationsprotokoll.
Wenn das Fortsetzen Teil des ursprünglichen Fehlers war, halten Sie den früheren Fehlerpfad des Fortsetzungstokens getrennt von einer fehlenden Abstammung, damit dasselbe Symptom Sie nicht erneut zur falschen Reparatur führt.
Die Wiederherstellung ist erfolgreich, wenn die neue Basisübertragung lesbar ist, die zweite inkrementelle Übertragung die erwartete Delta-Größe hat und erfolgreich abgeschlossen wird und die erwarteten Snapshots und Dateien nach einem Neustart oder einem planmäßigen Durchlauf vorhanden sind. Bewahren Sie die frühere Replik auf, bis diese Prüfungen bestanden sind. Eskalieren Sie den Vorgang, wenn sich Identitäten erneut ändern, das Ziel nicht schreibgeschützt bleiben kann oder das Werkzeug wiederholt eine unerwartete Basis auswählt.
Support & Tipps
Mehr zum Lesen

So planen Sie Restic-Aufgaben für Backup, Forget und Prune ohne Sperrkonflikte
Ein vollständiger Restic-Zeitplan für mehrere Hosts, der häufige Backups, eine gezielte Aufbewahrung, physisches Pruning, Prüfungen, Wiederholungsversuche und die Validierung von Wiederherstellungen voneinander trennt.

So verhindern Sie, dass Restic-Prune-Aufträge geplante Backups blockieren
Ein Präventionsplan für gemeinsam genutzte Restic-Repositories, der Sicherungsfenster von Prune trennt und Sperren, Wiederholungsversuche sowie Warnmeldungen beibehält.

So entfernst du eine veraltete Restic-Sperre, ohne eine aktive Sicherung zu unterbrechen
Ein möglichst wenig invasiver Restic-Entsperr-Workflow, der aktive Backups schützt, nur veraltete Zustände entfernt und die Wiederherstellung im Rahmen des normalen Zeitplans bestätigt.

