Migrationsleitfaden für Borg Backup zum Verschieben eines Repositorys auf einen neuen Speicher

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Borg Backup Migration Guide for Moving a Repository to New Storage - Zima Store Online

Der sichere Ansatz besteht darin, die Schreibvorgänge anzuhalten, je nach Version mit der geeigneten Methode zu kopieren oder zu übertragen, das Ziel zu verifizieren und die Umstellung mit Rollback als Abfolge beobachtbarer Prüfpunkte durchzuführen, nicht als einzelnen Befehl.

Bei einem BorgBackup-Repository auf lokalem, NAS- oder per SSH zugänglichem Speicher besteht das praktische Risiko darin, ein Borg-Repository verschieben zu müssen, ohne eine Aufspaltung oder eine unbemerkt unvollständige Kopie zu erzeugen. Erfassen Sie die aktuelle Identität und den Wiederherstellungspunkt, beginnen Sie mit dem am wenigsten invasiven Unterscheidungsmerkmal, werten Sie erfolgreiche und fehlgeschlagene Ergebnisse aus, bevor Sie eine weitere Variable ändern, und stoppen Sie, sobald der Speicher instabil wird oder die einzige wiederherstellbare Kopie gefährdet wäre. Der folgende Ablauf endet erst, wenn die ursprüngliche Arbeitslast erfolgreich ausgeführt wird oder die Beweislage eine Eskalationsgrenze erreicht.

Repository-Vereinbarung vor dem Kopieren dokumentieren

Speichern Sie die Borg-Version, die Repository-URL, die Repository-ID, den Verschlüsselungsmodus, den Speicherort des Schlüssels, den Wiederherstellungsprozess für die Passphrase, die Archivliste, die Größe, den freien Speicherplatz, die Append-only-Einstellungen sowie jeden Client und Automatisierungsjob, der Schreibzugriff hat. Das Repository kann nicht allein aus einem lokalen Cache wiederhergestellt werden, und verschlüsselte Repositorys können von Schlüsselmaterial abhängen, das außerhalb des Ziels gespeichert ist.

Der ZimaSpace-Artikel über eine Anleitung zur Wiederherstellung nach dem Verlust des Borg-Caches unterscheidet zwischen wiederaufbaubarem Cache-Zustand und fehlenden Schlüsseln oder beschädigten Repositorys. Führen Sie diese Prüfung vor der Migration durch, damit ein Schlüsselproblem nicht erst entdeckt wird, nachdem der alte Speicher entfernt wurde.

Entscheiden Sie, ob es sich um eine bytegenaue Verlagerung desselben Repositorys oder um eine Übertragung in ein neu initialisiertes Repository handelt. Borg-Version und -Format bestimmen, welche Methoden verfügbar sind; vermischen Sie keine Befehlsbeispiele für Borg 1 und Borg 2 und gehen Sie nicht automatisch davon aus, dass sich die Repository-Identität ändern sollte.

Schreibvorgänge anhalten und einen konsistenten Quellpunkt erstellen

Deaktivieren Sie Timer, Cronjobs, Container und Remote-Clients und bestätigen Sie anschließend, dass kein Borg-Prozess und keine Repository-Sperre aktiv ist. Führen Sie borg list und ein geeignetes borg check aus, bevor Sie kopieren. Wenn die Quelle die Prüfung nicht besteht, bewahren Sie sie auf und diagnostizieren Sie diesen Zustand, anstatt die Unsicherheit in das Ziel zu klonen.

Eine Diskussion auf Super User hebt das Risiko hervor, ein aktives Repository mit rsync zu kopieren, während sich ein dedupliziertes Borg-Repository verändert. Die sichere Regel lautet, ein angehaltenes Repository zu kopieren oder einen Dateisystem-Snapshot zu verwenden, der erstellt wurde, nachdem alle Borg-Schreibvorgänge gestoppt wurden, damit Indizes, Segmente, Nonce-Zustand und Daten zu einem einzigen Zeitpunkt gehören.

Lassen Sie die Backup-Zeitpläne deaktiviert, bis die Validierung des Ziels abgeschlossen ist. Wenn die Ausfallzeit zu lang ist, erstellen Sie eine erste Kopie, während das Repository inaktiv ist, stoppen Sie die Schreibvorgänge und führen Sie anschließend eine abschließende Synchronisierung durch; lassen Sie niemals zu, dass Quelle und Ziel während der Umstellung unabhängige Backups annehmen.

Mit der von Ihrer Borg-Version unterstützten Methode kopieren

Bewahren Sie bei einer Verlagerung desselben Repositorys mit einem geeigneten lokalen oder entfernten Kopierwerkzeug alle Dateien, Berechtigungen, das Verhalten von Sparse-Dateien und Eigentümerinformationen und prüfen Sie dessen Fehlerprotokoll. Kopieren Sie das Repository-Stammverzeichnis als Einheit und nicht einzelne Archive oder scheinbar große Datenverzeichnisse. Lassen Sie die Quelle nach der abschließenden Synchronisierung unverändert.

Verwenden Sie bei einem neuen Repository oder einer Formatmigration die Übertragungsfunktion nur, wenn sie von den installierten Borg-Versionen und dem Verschlüsselungsplan unterstützt wird. Eine Antwort auf Server Fault beschreibt die Übertragung eines Borg-Repositorys als die mit Borg 2 verbundene Richtung von Repository zu Repository, die nicht mit einer Dateisystemkopie unter Borg 1 austauschbar ist.

Stellen Sie das Ziel nach dem Kopieren zunächst schreibgeschützt für Clients bereit. Wenn Repository-ID, Schlüsselzugriff, Berechtigungen oder Format unerwartet sind, stoppen Sie den Vorgang und korrigieren Sie das Ziel; führen Sie keine „Initialisierung“ über kopierten Daten aus und verwenden Sie keine Reparatur, um die Erkennung zu erzwingen.

-15% OFF

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

Single board computer zimaboard2

Archive verifizieren, Clients umstellen und Rollback beibehalten

Führen Sie am Ziel borg list, borg info sowie die geeigneten Repository- und Archivprüfungen aus. Extrahieren Sie Testdateien aus einem aktuellen und einem älteren Archiv in ein separates Verzeichnis und vergleichen Sie Inhalte, Metadaten und Berechtigungen. Testen Sie mit derselben Borg-Binärdatei und demselben Remote-Pfad, den die Automatisierung verwenden wird.

Aktualisieren Sie einen Client auf die neue URL, löschen oder erstellen Sie nur den von Borg als erforderlich identifizierten Cache-Zustand neu und erstellen Sie ein kleines Testarchiv. Stellen Sie dieses Archiv wieder her und bestätigen Sie, dass die Zeitplanung für Pruning oder Compact deaktiviert bleibt, bis alle Clients den neuen Speicherort verwenden.

Die Umstellung ist erfolgreich, wenn der Archivbestand übereinstimmt, die Prüfungen bestanden werden, zwei Wiederherstellungen nutzbar sind und nach einem Neustart oder Neustart des Schedulers ein neues Backup erfolgreich erstellt wird. Belassen Sie die Quelle mindestens einen normalen Zyklus lang schreibgeschützt; löschen Sie sie erst nach Ablauf der Rollback-Frist oder eskalieren Sie den Vorgang, wenn sich die Prüfungen zwischen Quelle und Ziel unterscheiden.