Warum melden Restic oder Borg nach einer Änderung des Einhängepunkts, dass ein Repository fehlt oder verschoben wurde?

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.

Why Does Restic or Borg Report a Missing or Relocated Repository After a Mount-Point Change? - Zima Store Online

Restic oder Borg können den Eindruck erwecken, ein Repository vergessen zu haben, wenn der konfigurierte Pfad nun auf ein leeres Verzeichnis, ein anderes Dateisystem oder die verschobene Identität eines Repositorys verweist.

Die Repository-Daten können auf der Backup-Festplatte weiterhin intakt sein. Der Auftrag kann jedoch das leere Mount-Verzeichnis öffnen, bevor die Festplatte verfügbar ist, einen geänderten Container-Pfad verwenden, eine veraltete Umgebungsvariable auslesen oder ein Borg-Repository ablehnen, dessen ID an einem neuen Speicherort erscheint. Diagnostizieren Sie die eingehängte Quelle und die Repository-Identität, bevor Sie etwas initialisieren. Wenn Sie einen Init-Befehl am falschen, leeren Pfad ausführen, kann dadurch ein zweites Repository erstellt und die ursprüngliche Ursache verschleiert werden.

Bestätigen, was am konfigurierten Repository-Pfad eingehängt ist

Notieren Sie den vom geplanten Auftrag verwendeten Repository-Pfad und vergleichen Sie ihn vor und nach dem Einhängen der Backup-Festplatte. Erfassen Sie die Dateisystemquelle, UUID, den Einhängepunkt und die verfügbare Kapazität.

Das Linux-Dienstprogramm findmnt ermittelt die aktive Einhängung hinter einem Zielpfad. Daher ist es die richtige erste Prüfung, wenn ein vertrautes Verzeichnis in Wirklichkeit der nicht eingehängte Ordner des Hostsystems sein könnte.

Wenn der Pfad zum Root-Dateisystem statt zur Backup-Festplatte gehört, beenden Sie den Backup-Dienst, bevor er ein neues Repository oder Backup-Set in diesem leeren Verzeichnis anlegt.

Den exakten Speicherort des Restic-Repositorys überprüfen

Vergleichen Sie den mit -r, --repository-file oder RESTIC_REPOSITORY übergebenen Pfad mit dem aktuellen Einhängepunkt. Prüfen Sie Wrapper-Skripte, NAS-Felder, Anmeldedatendateien und Umgebungen geplanter Aufgaben.

Restic definiert ein lokales Repository als ein bestimmtes Verzeichnis, das Konfiguration, Daten, Index, Schlüssel, Sperren und Snapshots enthält. Wenn sich der Einhängepunkt ändert, ändert sich daher auch der Speicherort, den der Befehl zu öffnen versucht.

Führen Sie restic init nicht einfach deshalb aus, weil am neuen Pfad gemeldet wird, dass kein Repository vorhanden ist. Suchen Sie zuerst die Konfigurations- und Datenverzeichnisse des ursprünglichen Repositorys auf der eingehängten Festplatte.

Die Warnung über ein verschobenes Borg-Repository bewusst behandeln

Notieren Sie die Borg-Repository-URL, die Repository-ID, den früheren und aktuellen Speicherort, den Cache-Pfad sowie das Sicherheitsverzeichnis. Bestätigen Sie, dass dasselbe Repository absichtlich verschoben wurde.

Borg erklärt in seinen FAQ, dass es nach einer Verschiebung des Repositorys eine Genehmigung anfordert, weil dieselbe Repository-ID an einem neuen Pfad auch auf einen unsicheren Austausch hindeuten kann.

Genehmigen Sie die Verschiebung erst, nachdem Sie Repository-ID und Speicherinhalte verglichen haben. Unterdrücken Sie die Warnung nicht global, wenn mehrere Wechseldatenträger unter wechselnden Pfaden verbunden sein können.

-15% OFF

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

Single board computer zimaboard2

Pfade mit Geräte-Reihenfolge durch eine dauerhafte Speicheridentität ersetzen

Prüfen Sie, ob die Einhängekonfiguration auf /dev/sdX, ein doppeltes Label, eine Dateisystem-UUID, eine Partitions-UUID oder eine Geräte-ID verweist. Vergleichen Sie alle rotierenden Festplatten auf doppelte Kennungen.

ArchWiki weist darauf hin, dass UUIDs Namenskollisionen reduzieren – im Vergleich zu Labels und vom Kernel vergebenen Gerätenamen, die sich je nach Erkennungsreihenfolge ändern können.

Eine stabile Kennung muss dennoch dem vorgesehenen festen Einhängeverzeichnis zugeordnet sein. UUIDs verhindern eine Verschiebung durch eine andere Festplattenreihenfolge, ändern jedoch keinen Backup-Auftrag, der weiterhin den früheren Pfad enthält.

Pfadübersetzung bei Containern und Bind-Mounts prüfen

Bei einem containerisierten Restic, Borg oder einer Backup-Oberfläche vergleichen Sie den Einhängepunkt des Hosts mit der Quelle des Bind-Mounts und dem Repository-Pfad innerhalb des Containers. Prüfen Sie den laufenden Container und nicht nur die gespeicherte Compose-Datei.

Docker dokumentiert, dass Bind-Mounts vom exakten Host-Pfad abhängen. Wenn eine Festplatte also von /mnt/backup-a nach /media/backup-a verschoben wird, kann der Container weiterhin auf ein leeres Verzeichnis zeigen.

Behalten Sie den stabilen Hardware-Pfad auf dem Host bei und stellen Sie einen stabilen Container-Pfad bereit. Speichern Sie hostspezifische Pfade für Wechseldatenträger nicht direkt in der Repository-Konfiguration, wenn eine feste Zuordnung verfügbar ist.

Den Backup-Dienst auf das Einhängen warten lassen

Vergleichen Sie die Zeitstempel von Systemstart und Diensten. Bestätigen Sie, dass das Einhängen abgeschlossen war, bevor der Backup-Planer, Container, die Repository-Oberfläche oder eine Wartungsaufgabe auf das Repository zugreifen wollte.

Die Anleitung von Red Hat für dauerhafte Einhängungen empfiehlt, einen festen Eintrag in fstab zu definieren, der anschließend mit Dienstabhängigkeiten und einer Prüfung vor dem Start kombiniert werden kann.

Die Boot-Option nofail kann für eine entfernbare Backup-Festplatte geeignet sein. Der Backup-Dienst muss den Start jedoch weiterhin verweigern, wenn das erforderliche Dateisystem fehlt.

Das vorhandene Repository wieder verbinden, bevor ein Backup ausgeführt wird

Stoppen Sie geplante Aufträge, hängen Sie das vorgesehene Dateisystem am festen Pfad ein, überprüfen Sie die Repository-Struktur, öffnen Sie das Repository schreibgeschützt oder listen Sie Snapshots auf und führen Sie eine kleine Repository-Prüfung durch, bevor Sie Schreibzugriffe wieder aktivieren.

Der ZimaSpace-Artikel über stabile App-Pfade auf UUID-Basis behandelt die allgemeine Einhängekette. Dieser Artikel konzentriert sich auf Repository-Identität und die Sicherheit von Backup-Tools nach einer Pfadänderung.

Das Problem ist behoben, wenn dieselbe Repository-ID und derselbe Snapshot-Verlauf nach wiederholten Tests mit Neustarts und Festplattenwechseln am vorgesehenen Pfad geöffnet werden können und kein neues Repository im leeren Einhängeverzeichnis erstellt wurde.

Häufig gestellte Fragen

Kann ein Restic-Repository an einen anderen Einhängepunkt verschoben werden?

Ja, sofern das vollständige Repository unverändert verschoben wird und nun jeder Auftrag auf den neuen Speicherort verweist. Restic identifiziert das Repository anhand des Pfads oder Backends, das an den Befehl übergeben wird.

Warum warnt Borg, wenn die Repository-Daten unverändert sind?

Borg speichert die Repository-Identität und den früheren Speicherort als Sicherheitsmaßnahme. Das Auftreten derselben ID an einem anderen Pfad erfordert eine bewusste Genehmigung.

Soll ich am neuen Pfad ein Repository initialisieren?

Nein, nicht bevor Sie nachgewiesen haben, dass das alte Repository nicht vorhanden ist. Durch die Initialisierung eines leeren Einhängepunkts wird ein separates Repository erstellt, statt das ursprüngliche wieder zu verbinden.