Restic: Backup-Option zum Entfernen eines führenden Pfadpräfixes

Erstellt am 16. Nov. 2018  ·  24Kommentare  ·  Quelle: restic/restic

Ausgabe von restic version

restic 0.9.3 compiled with go1.11.1 on linux/amd64

Was sollte restic anders machen? Welche Funktionen sollten wir Ihrer Meinung nach hinzufügen?

Es wäre hilfreich, eine Option für restic backup , die besagt, "diesen führenden Pfad von den Pfaden aller gesicherten Dateien entfernen". Beispiel: --backup-root /some/path . Dies hätte folgende Auswirkungen:

  • Eine Datei /some/path/to/file würde im Snapshot als /to/file gespeichert.
  • Bei dieser Datei würde auch die Metadatenprüfung gegen /to/file im übergeordneten Snapshot durchgeführt.
  • Sie dürfen keine Dateien/Verzeichnisse für restic backup angeben, die nicht mit diesem Präfix beginnen.

(Ich denke, dies könnte mit # 1376 zusammenhängen.)

Was versuchst du zu machen?

Eines unserer Backup-Skripte wird auf einem System mit vielen laufenden Diensten ausgeführt, die nicht gestoppt werden können. Diese Dienste garantieren, dass eine Wiederherstellung ab einem bestimmten Zeitpunkt möglich ist (zB führen sie genügend Journaling durch, um ihre Daten nach einem Stromausfall wieder in einen konsistenten Zustand zu bringen). Restic Backups sind jedoch nicht atomar; Daher brechen restic Backups die Wiederherstellungsgarantie des Dienstes.

Um dies zu beheben, gehen wir wie folgt vor:

  1. Machen Sie einen LVM-Snapshot von / . Der Snapshot ist eine atomare Kopie des gesamten Volumes auf Blockebene.
  2. Mounten Sie den LVM-Snapshot unter /mnt/backup-snapshot .
  3. Führen Sie das Restic-Backup gegen /mnt/backup-snapshot .
  4. Unmounten Sie den LVM-Snapshot.
  5. Löschen Sie den LVM-Snapshot.

Dadurch wird das Backup wirklich zeitpunktbezogen und garantiert, dass das wiederhergestellte Backup effektiv in einem konsistenten Zustand ist.

Leider führt dies auch dazu, dass Dateien in unserem restic Repository mit dem (nutzlosen) Präfix /mnt/backup-snapshot gespeichert werden. Dies kann Wiederherstellungsbemühungen erschweren und ist auch etwas verwirrend, wenn Sie nicht wissen, wie das Backup erstellt wurde.

Die einzige machbare Problemumgehung, die mir einfällt, besteht darin, das Backup in einem Chroot auszuführen. Obwohl es nicht das Ende der Welt ist, könnte es für restic besser sein, eine Option bereitzustellen, um einige führende Präfixe aus Dateien zu entfernen.

backup need direction feature suggestion

Hilfreichster Kommentar

Hallo zusammen, ich habe angefangen, an der Implementierung dieser "benutzerdefinierten Root"-Funktion zu arbeiten. Die Implementierung selbst war scheinbar einfach, obwohl ich Golang lernen musste, da ich bisher nur C# kannte ... Wie auch immer, ich versuche abzuschätzen, welche Art von Unterstützung dieses Problem noch hat, da es von 2018 vor 2 Jahren stammt . Ich werde mich bald auf https://github.com/TheRealVincentVanGogh/restic/tree/2092-feature-custom-path-prefix festlegen, falls mir jemand mit Golang helfen möchte 😅. Hoffentlich werde ich bald später hier eine Pull-Anfrage stellen.

Alle 24 Kommentare

Hier ist eine ältere Inkarnation dieser Bitte, die ich gefunden habe: #555

+1

Ich denke auch, dass dies eine wirklich nützliche Funktion wäre.

Lassen Sie mich zusammenfassen: Sie führen restic backup /mnt/backup-snapshot , also ist die Datei /mnt/backup-snapshot/foo /mnt/backup-snapshot/foo im Snapshot, aber Sie möchten, dass sie /foo . Ist das korrekt?

Sie können dies mit restic > 0.9.0 erreichen, indem Sie das aktuelle Verzeichnis ändern, indem Sie einfach cd /mnt/backup-snapshot und dann restic backup . ausführen.

Funktioniert das für dich?

Das Ändern von cwd funktioniert, aber ich habe festgestellt, dass es einen unangenehmen Nebeneffekt gibt, wenn Dateien zum Einschließen/Ausschließen verwendet werden. Es scheint, dass, wenn dort absolute Pfade platziert werden, diese beim Ändern von cwd übersprungen werden. Ich würde auch viel lieber absolute Pfade verwenden - für jetzt werde ich wahrscheinlich den Chroot-Pfad entlang gehen, aber ich stimme zu, es wäre schöner, etwas Ähnliches wie das -C Flag in tar .

Ich denke, diese gefälschte Root-Option wäre eine nützliche Funktion. Ich würde gerne das gleiche wie cdhowie machen, aber mit apfs-Snapshot auf macOS. Um auf die schreibgeschützten apfs-Snapshots zuzugreifen, müssen sie irgendwo gemountet werden. Aber beim Wiederherstellen möchte ich, dass der "ursprüngliche" Pfad der im Snapshot gespeicherte kanonische Pfad ist.

Der CD-Trick ist leider nicht optimal, da ich viele (125) absolute Pfade aus der StdExclusions.plist (macOS-Standard-Backup-Ausschlussliste) gesammelt habe und alle Dateien und Ordner, die mdfind mit dem Attribut com_apple_backup_excludeItem finden kann.

Belässt das Problem einfach, wenn Sie /mnt in die Ignore-Datei einfügen und das Backup von /mnt/fs-snapshot starten, wird es sich selbst ausschließen.

Plus cd $path && restic backup . gibt immer noch $path in der Snapshot-Übersicht an, während Pfade im Snapshot /-basiert sind.

Ich habe einen Workaround mit Proot gefunden.

Ich wollte auch eine Möglichkeit finden, das Pfadpräfix zu entfernen. Mein Anwendungsfall ist etwas anders - ich erstelle einen ZFS-Snapshot ( fs@$(date +%s) ) und wollte diesen sichern, ohne ihn mounten zu müssen ( /path/to/mount/.zfs/snapshots/${TS} ) - auf diese Weise habe ich hoffentlich nicht sich Sorgen zu machen, dass der Snapshot nicht ausgehängt wird und dann ewig herumhängt, falls etwas abstürzt.

Die Ausgabe von restic forget lässt mich denken, dass Snapshots mit unterschiedlichen Pfaden gemäß dem Zeitplan (täglich / wöchentlich / etc.) nicht vergessen werden.

Der Kommentar proot von @blurayne war ein

$snap_path="/path/to/where/snapshot/is/accessible"
$orig_fs="/path/to/filesystem"
proot -b "${snap_path}":"${orig_fs}" restic backup "${orig_fs}"

Das funktioniert gut, und jetzt haben alle Snapshots denselben Pfad, ohne dass cd oder pushd erforderlich sind. Außerdem ist Proot im User-Space verfügbar. Wenn also Backups nicht als Root durchgeführt werden, ist dies immer noch möglich.

Mein Anwendungsfall: Datenbankdaten in ein temporäres Verzeichnis wie /tmp/tmpzmn28r02 (erhalten über mktemp oder mkdtemp() von Python) ausgeben und dann sichern.
Diese Methode markiert alle Dateien zwischen 2 Snapshots als unterschiedlich. Ich brauche also eine Möglichkeit, restic anzuweisen, das temporäre Verzeichnispräfix vollständig zu ignorieren.
Ein weiterer möglicher Anwendungsfall: Heute habe ich alle meine Bilder in '/mnt/something/pictures', aber morgen wird der gleiche Inhalt unter '/mnt/external/pictures-from-home' sein (anderes Partitionsschema/was auch immer)

Auch wenn Sie restic verwenden und mehrere Verzeichnisse im selben Durchlauf sichern möchten, um denselben Snapshot zu verwenden, wird dies noch komplizierter.

Bis ein Fix fertig ist, werde ich den 'Proot'-Vorschlag verwenden - danke @blurayne und @whi-tw

Hallo! Ich habe einen ähnlichen Fall. Zum Beispiel habe ich Ordner

/srv/my/long/server1/path/data (with many subfolders and dozen of files)
/path/to/dump.sql
/path/certbot.tar.gz

Also möchte ich ein Backup bekommen wie

/data
/dump.sql
/certbot.tar.gz

und die Möglichkeit erhalten, auf einem anderen Server (ich kenne die vorherige Ordnerstruktur nicht) über einen anderen Pfad (relativ) wiederherzustellen.

Ich habe keine heißen Ideen, um diese triviale Aufgabe zu lösen. Restic ist ein erstaunliches Werkzeug, aber ... warum funktioniert es für Endbenutzer so schwierig?

Ich kopiere in einen vordefinierten Backup-Ordner (/backup) alles was ich brauche und führe dort Restic Backup (über CD) aus. Diese Lösung funktioniert jedoch nur bei kleinen Datenmengen.

Es wird großartig sein, die Fähigkeit zur Wiederherstellung mit --include Unterordner direkt nach der Vorlage (oder einschließlich dieser Maske) zu haben. Ex.:
restic restore --include data --target /my/new/path
und als Ergebnis erhalten
/my/new/path/data


Danke @whi-tw für die Lösung mit proot -b /path/i/wanted:./path_in_repo restic backup . - bei mir funktioniert es.

Mein Anwendungsfall ist die Migration von Snapshots von anderen Backup-Lösungen zu Restic (in meinem Fall Time Machine und Disk-Images).

Ich migriere sie von dort, wo ich das Image oder das Unterverzeichnis des von TM erstellten Snapshots mounte, was sehr lang werden kann, zB /Volumes/TimeMachine-Backups/Backups.backupdb/MacBook Pro/2019-05-22-185113/Macintosh SSD/ .

Die Lösung cd funktioniert, wenn restic mount und restic restore , aber der absolute Pfad des ursprünglichen Snapshots wird aufgelistet, wenn ich restic snapshots ausführe.

Da es sich um einen migrierten Snapshot handelt, möchte ich, dass dies auch der Pfad ist, von dem aus der ursprüngliche Snapshot erstellt wurde. Abgesehen davon macht es bei den langen Pfaden auch die Ausgabe von restic snapshots etwas verrauscht.

Ein Flag zum Setzen eines alternativen Präfixes wäre auch für mich ideal.

Dies funktioniert gut, und jetzt haben alle Snapshots denselben Pfad, ohne dass cd oder pushd erforderlich sind. Außerdem ist Proot im User-Space verfügbar. Wenn also Backups nicht als Root durchgeführt werden, ist dies immer noch möglich.

Dies wäre ein netter Workaround gewesen, aber proot ist auf macOS nicht verfügbar und scheint in absehbarer Zeit nicht zu kommen (der größte Teil des speziell für Linux geschriebenen Codes): Funktioniert PRoot auf MacOSX?

Fällt mir noch eine andere Problemumgehung ein?

Mein Anwendungsfall: Datenbankdaten in ein temporäres Verzeichnis wie /tmp/tmpzmn28r02 (erhalten über mktemp oder mkdtemp() von Python) ausgeben und dann sichern.
Diese Methode markiert alle Dateien zwischen 2 Snapshots als unterschiedlich.

Beachten Sie, dass die Dateien wahrscheinlich sowieso unterschiedlich sind; Datenbanksicherungen enthalten normalerweise in den ersten Zeilen einen Zeitstempel.

Sie können Datenbank-Dump-Befehle optimieren, um dynamische Kommentare auszuschließen und nach Primärschlüsseln sortiert zu werden, um sich langsam ändernde Daten wirklich deduplizierbar zu machen

Ein Update: 'proot' hat bei mir nur auf einer Maschine funktioniert, auf einer anderen segfaults.
Eine Alternative dazu (neuer) - Luftpolsterfolie
Darüber wurde ein Wrapper hinzugefügt (angehängt), der mit den gleichen '-b'-Parametern funktionieren sollte. Es scheint soweit zu funktionieren. Beachten Sie, dass Sie den Wrapper je nach Ihren Anforderungen und Verzeichnisspeicherorten möglicherweise ein wenig ändern müssen.
Ich hoffe, es hilft euch, aber ich freue mich auf die Unterstützung innerhalb von restic.

proot.sh.txt

Ich habe es mit proot versucht. Es scheint die Möglichkeit zu unterbrechen, restic als Nicht-Root mit zusätzlichen Funktionen auszuführen (https://restic.readthedocs.io/en/stable/080_examples.html#full-backup-ohne-root); zumindest habe ich scan: Open: open /.pulse: permission denied Fehler bekommen, die ich nicht bekam, wenn ich restic ohne proot ausführte.

Gleiches Problem mit bwrap .

Daher erscheint mir das Entfernen eines Pfadpräfixes in Restic selbst immer noch nützlich.

Diese fehlende Funktion macht es schwieriger als nötig, VMs zu sichern.
Meine VM-Snapshots landen in einem temporären Ordner und werden dann von restic gesichert.
Daraus ergibt sich folgendes:

ID        Time                 Host         Tags        Paths
--------------------------------------------------------------------------------------
02c536db  2020-04-10 14:28:27  resolver-02              /tmp/tmp.vOFFxxly9O/config.xml
c5709aed  2020-04-10 14:28:29  resolver-02              /tmp/tmp.vOFFxxly9O/sdb.img
a88cc1e7  2020-04-10 14:36:22  resolver-02              /tmp/tmp.FoY1j5JPIZ/config.xml
7c44e6ee  2020-04-10 14:36:24  resolver-02              /tmp/tmp.FoY1j5JPIZ/sdb.img
65456111  2020-04-10 14:37:48  resolver-02              /tmp/tmp.vjtI9JE3Iz/config.xml
eaced756  2020-04-10 14:37:49  resolver-02              /tmp/tmp.vjtI9JE3Iz/sdb.img
8eccec2c  2020-04-10 16:04:30  resolver-02              /tmp/tmp.YtLYRd0rNI/config.xml
34c897e1  2020-04-10 16:04:31  resolver-02              /tmp/tmp.YtLYRd0rNI/sdb.img
99b67b97  2020-04-10 16:07:53  resolver-02              /tmp/tmp.aWaEDqAaTq/config.xml
cad2c9d8  2020-04-10 16:07:54  resolver-02              /tmp/tmp.aWaEDqAaTq/sdb.img
--------------------------------------------------------------------------------------

Dies bricht restic forget weil es nicht erkennt, dass es sich um dieselbe Datei handelt, und speichert für jede Instanz einen Snapshot. Ich würde es vorziehen, wenn es eine Möglichkeit gäbe, entweder ein bekanntes Präfix zu entfernen oder nur einen relativen Pfad zu speichern, keinen absoluten.
Ich rufe bereits restic mit einem relativen Pfad und ching im temporären Ordner auf. Hilft leider nicht und ich würde es vorziehen, dafür keine Bindmounts verwenden zu müssen.

Dies bricht restic forget da es nicht erkennt, dass es sich um dieselbe Datei handelt und für jede Instanz einen Snapshot erstellt.

Wir stoßen auch darauf, aber die Lösung ist ziemlich einfach: Markieren Sie jedes Backup basierend auf den Dateien, die gesichert werden.

Beispielsweise könnten Sie hier die Tags config.xml und sdb.img . Fügen Sie dann --group-by host,tags wenn Sie restic forget .

Was macht diese Funktion so schwer zu implementieren? Handelt es sich nicht um dieselbe grundlegende String-Filterung für Snapshot-Metadaten? Der Wert, den es bringen würde, ist enorm. Ja, Sie können das Tagging umgehen, aber es gibt ein Pfadfeld und es könnte verwendet werden ...

Was macht diese Funktion so schwer zu implementieren?

Apropos Entwickler (nicht von restic, sondern von anderen Open-Source-Projekten): Oft ist es nicht die Komplexität eines Features, das die Umsetzung verhindert, sondern banale Dinge wie Zeitmangel, Motivation oder einfach das "real life"...

Natürlich wollte ich nicht kritisch sein, sondern wirklich versuchen, die Komplexität für potenzielle Mitwirkende abzubilden

Hallo zusammen, ich habe angefangen, an der Implementierung dieser "benutzerdefinierten Root"-Funktion zu arbeiten. Die Implementierung selbst war scheinbar einfach, obwohl ich Golang lernen musste, da ich bisher nur C# kannte ... Wie auch immer, ich versuche abzuschätzen, welche Art von Unterstützung dieses Problem noch hat, da es von 2018 vor 2 Jahren stammt . Ich werde mich bald auf https://github.com/TheRealVincentVanGogh/restic/tree/2092-feature-custom-path-prefix festlegen, falls mir jemand mit Golang helfen möchte 😅. Hoffentlich werde ich bald später hier eine Pull-Anfrage stellen.

@TheRealVincentVanGogh Ich werde Go nicht lernen, aber ich bin immer noch eifrig auf diese Funktion und habe eine Menge Backups, die ich bis auf dieses Problem immer noch auf Restic portieren möchte. Öffnen Sie eine PR, sobald Sie etwas haben, das so aussieht, als ob es funktioniert, und posten Sie den Link hier, ich werde einige Tests durchführen

@TheRealVincentVanGogh Wie hängt Ihre geplante Implementierung mit PR #2010 zusammen?

@TheRealVincentVanGogh Wie hängt Ihre geplante Implementierung mit PR #2010 zusammen?

@MichaelEischer Oh schießen! Sieht so aus, als hätte mich schon jemand geschlagen. Ja, PR #2010 ist genau das, was ich gerade mittendrin bin... wieder vollenden... Verdammt. Vielleicht könnte @cdhowie PR #2010 mit dieser Ausgabe verlinken, um zukünftige Verwirrung zu vermeiden? Danke!

@themightychris Hier ist ein Link zu dieser PR . Sieht so aus, als ob die Entwickler 2018 auch ausgeschieden sind ... neugierig.

Bearbeiten:

Es scheint eine gewisse Mehrdeutigkeit zwischen dem Entfernen eines Pfadpräfixes aus der Snapshot-Datei VS. Entfernen eines Pfadpräfixes aus jeder Dateistruktur + Snapshot-Datei. Sieht so aus, als ob PR #2010 nur ersteres anspricht. Da OP nach "diesen führenden Pfad von den Pfaden aller gesicherten Dateien entfernen ich zurücknehmen, was ich über die Verknüpfung von PR #2010 mit dieser Ausgabe gesagt habe . Sorry für die Erwähnung cdhowie!

Dennoch! @MichaelEischer Meine Absicht war immer, eine Dateistruktur + Pfadpräfix-Slicing-Implementierung auf Snapshot-Ebene in Restic zu erhalten (Mann, das ist eine lange Funktion / ein langer Satz). Also werde ich höchstwahrscheinlich damit beginnen, an dem bestehenden Code von PR #2010 zu arbeiten, was die Implementierung beschleunigen sollte.

PS Ich bin heutzutage ziemlich beschäftigt, daher kann die Arbeit für eine Weile langsam sein; Natürlich werde ich eine PR veröffentlichen, wenn ich denke, dass ich etwas habe, das es wert ist, mit euch allen zu teilen! Bleiben Sie alle sicher! 😄

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen