So verschieben Sie ein USB-Backup-Repository an einen neuen Einhängepfad, ohne den inkrementellen Verlauf zu beschädigen

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.

How to Move a USB Backup Repository to a New Mount Path Without Breaking Incremental History - Zima Store Online

Das Verschieben eines USB-Backup-Repositorys zu einem neuen Einhängepfad ist sicher, wenn das Repository selbst intakt bleibt und der Backup-Auftrag gezielt wieder damit verbunden wird.

Der gefährliche Fehler besteht darin, den neuen Pfad als neues Ziel zu behandeln und die Backup-Anwendung ein leeres Repository neben dem alten initialisieren zu lassen. Bevor Sie Bezeichnungen, Einhänge-Regeln oder die Verzeichnisstruktur ändern, sollten Sie die physische Dateisystemidentität, das Repository-Stammverzeichnis, die Repository-ID, sofern das Tool eine solche anzeigt, die Verschlüsselungsdaten, die Auftragskonfiguration und den letzten nutzbaren Wiederherstellungspunkt dokumentieren. Verschieben oder hängen Sie das vorhandene Repository anschließend als eine Einheit um und stellen Sie vor dem nächsten Schreibvorgang sicher, dass die Anwendung dessen bisherige Historie erkennt.

Vor der Pfadänderung das vorhandene Repository dokumentieren

Speichern Sie die aktuelle Einhängequelle, die UUID oder Bezeichnung des Dateisystems, das Repository-Verzeichnis, den Namen des Auftrags, den Speicherort des Verschlüsselungsschlüssels oder Kennworts sowie die eigene Kennung des Repositorys, sofern das Backup-Tool eine solche bereitstellt. Listen Sie mehrere aktuelle Snapshots oder Archive als Ausgangsbasis auf.

Kopia trennt die Erstellung eines Repositorys vom Verbinden mit einem vorhandenen Repository. Diese Unterscheidung sollte während einer Änderung des Einhängepfads unbedingt erhalten bleiben.

Beginnen Sie die Verlagerung erst, wenn Sie die alte Historie identifizieren können, ohne sich ausschließlich auf den Einhängepfad zu verlassen. Wenn Sie nur den Pfad dokumentiert haben, kann eine später dort eingehängte zweite USB-Festplatte täuschend echt wirken.

Das Repository als vollständige Einheit verschieben

Stoppen Sie den Backup-Auftrag sowie alle Prozesse zum Bereinigen, Komprimieren, Überprüfen oder Wiederherstellen, bevor Sie Repository-Dateien verschieben. Kopieren oder hängen Sie das vollständige Repository-Stammverzeichnis um, einschließlich Indizes, Konfiguration, Pack-Dateien, Sperren, dort gespeicherten Schlüsseln und tool-spezifischen Metadaten.

Borg beschreibt sein Repository als strukturierten transaktionalen Speicher mit Repository-Metadaten neben den Backup-Daten. Daher ist es kein sicheres Verlagerungsmodell, nur sichtbare, archivähnliche Dateien zu kopieren.

Lassen Sie das ursprüngliche Repository unverändert, bis der neue Pfad eine schreibgeschützte Auflistung oder Prüfung besteht. Vermeiden Sie es, die ursprüngliche und die kopierte Instanz für normale Schreibvorgänge gleichzeitig zu öffnen, wenn das Tool sie als Repositorys mit derselben Identität betrachtet.

Den Zielpfad ändern, ohne eine neue Historie zu initialisieren

Aktualisieren Sie den vorhandenen Auftrag oder die Repository-Verbindung auf den neuen Dateisystempfad. Wenn die Oberfläche zwischen Erstellen und Verbinden, Importieren, Erneut verknüpfen oder Vorhandenes verwenden unterscheidet, wählen Sie den Pfad für ein vorhandenes Repository und überprüfen Sie das Ziel vor dem Speichern.

Die Maintainer von Duplicati erklären, dass Sie nach dem Verschieben eines vorhandenen Speichers das Ziel bearbeiten und fortfahren können, wenn die Auftragsdatenbank auf den verlagerten Speicher verweist.

Wenn die Anwendung sofort anbietet, ein leeres Ziel zu initialisieren, brechen Sie ab. Das ist ein Hinweis darauf, dass sie das alte Repository noch nicht erkannt hat. Eine Initialisierung kann eine zweite Historie erzeugen und spätere Bereinigungen unübersichtlich machen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Damit rechnen, dass einige Tools eine Repository-Verlagerung erkennen

Ein Backup-Client kann sich mehr als nur den Inhalt des Repositorys merken. Lokale Caches können eine Repository-Identität mit dem bisherigen Speicherort verknüpfen und eine ausdrückliche Bestätigung verlangen, wenn dasselbe Repository an einem neuen Ort erscheint.

Bei einem Fall zur Änderung des Einhängepfads in Duplicacy geht es darum, ein verschobenes Repository erneut zu verknüpfen. Das zeigt, warum eine Änderung des Repositorypfads als erneute Verknüpfung und nicht als neue Initialisierung behandelt werden sollte.

Bestätigen Sie die Verlagerung erst, nachdem Sie Repository-Identität, erwartete Snapshots, Verschlüsselungsstatus und USB-Dateisystem abgeglichen haben. Eine Warnung auf der falschen Festplatte ist ein Grund zum Abbruch und kein Beweis dafür, dass die Software übervorsichtig ist.

Dem USB-Dateisystem eine stabile Einhängeidentität geben

Sobald das Repository erkannt wurde, ordnen Sie das physische USB-Dateisystem mithilfe eines geeigneten dauerhaften Identifikators einem festen, administrativ verwalteten Pfad zu. Vermeiden Sie es, geplante Backups an die Erkennungsreihenfolge von /dev/sdX oder an ein Einhängeverzeichnis einer Desktop-Sitzung zu binden.

Linux-Tools können Dateisysteme anhand einer stabilen Bezeichnung oder UUID identifizieren. Dadurch kann derselbe Repositorypfad gewöhnliche Änderungen bei der Geräteerkennung überstehen.

Wenn Sie die Bezeichnung eines Dateisystems absichtlich ändern, aktualisieren Sie die Einhänge-Regel und testen Sie sie, bevor Sie Backups wieder aktivieren. Die Backup-Anwendung sollte weiterhin dasselbe Repository-Stammverzeichnis sehen, auch wenn sich die lesbare Bezeichnung ändert.

Vor dem ersten Schreibvorgang nach dem Verschieben die Historie überprüfen

Hängen Sie die USB-Festplatte am neuen Pfad ein, verbinden Sie das vorhandene Repository, listen Sie frühere Snapshots auf, überprüfen Sie den neuesten Wiederherstellungspunkt und stellen Sie eine kleine Datei in ein temporäres Verzeichnis wieder her. Führen Sie erst danach das erste neue Backup aus.

Ein restic-Benutzerbeispiel weist darauf hin, dass ein lokales Repository umbenannt und anschließend wieder eingebunden werden kann. Das bestätigt, dass die Repository-Historie zum Inhalt des Repositorys gehört und nicht zur Schreibweise eines einzelnen Einhängepfads.

Die Verlagerung ist abgeschlossen, wenn alte Snapshots weiterhin durchsucht werden können, eine Testwiederherstellung funktioniert und das neue Backup an dieselbe Historie angehängt wird. Der zugehörige ZimaSpace-Artikel über USB-Einhängepfade, die sich nach einem Neustart ändern, ist die richtige Anlaufstelle, wenn die Pfadänderung ungeplant und keine kontrollierte Repository-Verlagerung war.

Häufig gestellte Fragen

Wird die Backup-Historie durch das Ändern der Bezeichnung eines USB-Datenträgers automatisch beschädigt?

Nicht unbedingt. Problematisch wird es, wenn die Einhänge-Regel oder der Backup-Auftrag diese Bezeichnung als Teil der Zielidentität verwendet und das Repository am erwarteten Pfad nicht mehr gefunden wird.

Sollte ich nur den Ordner mit dem neuesten Backup an den neuen Pfad kopieren?

Nein, nicht bei Repository-basierten Backup-Tools. Bewahren Sie die vollständige Repository-Struktur zusammen auf, da Indizes, Kataloge, Pack-Dateien, Schlüssel und ältere Wiederherstellungspunkte voneinander abhängen können.

Kann ich die alten und neuen Kopien des Repositorys gleichzeitig online lassen?

Bewahren Sie die alte Kopie als Quelle für einen Rückfall auf. Vermeiden Sie jedoch, unabhängig in zwei geklonte Instanzen mit derselben Repository-Identität zu schreiben, sofern das Backup-Tool diesen Ablauf nicht ausdrücklich unterstützt.