Vielen Dank, dass Sie dieses Problem gemeldet haben. Ich denke, dies ist ein Fehler.

Wird wahrscheinlich immer dann auftreten, wenn Verzeichnisse der obersten Ebene denselben Namen haben. Da der vollständige Pfad nicht wiederhergestellt wird, nur das Verzeichnis der obersten Ebene.

Die Lösung besteht darin, den vollständigen Pfad bei der Wiederherstellung zu rekonstruieren und jeden Baum im vollständigen Pfad wiederherzustellen. Der resultierende Pfad wäre also wie /tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ . Ich denke es ist akzeptabel.

Muss der Patch im Rahmen der Wiederherstellung implementiert werden?
Oder muss dies während der Sicherung durchgeführt werden, indem ein anderer Baum der obersten Ebene erstellt wird, der die vollständigen Pfadkomponenten enthält?

Ich vermute auch, dass dies der Fall ist. Im Moment funktioniert Restic folgendermaßen:

Beim Aufruf als restic backup A/foo B/foo wird eine Baumstruktur im Repository erstellt, die folgendermaßen aussieht:

├── foo
└── foo

Es wird also nur die letzte Pfadkomponente von den Argumenten zum Befehl backup . Dies führt zu einem Problem beim Wiederherstellen eines solchen Snapshots.

Um dies zu korrigieren, schlage ich vor, dasselbe Verhalten wie tar implementieren, wodurch in diesem Fall der folgende Baum erstellt wird:

.
├── A
│   └── foo
└── B
    └── foo

Dies erfordert einige Arbeiten im Archivierungsbereich von restic. Ich glaube nicht, dass wir die Wiederherstellung überhaupt berühren müssen.

588 Ich habe dasselbe gemeldet. Aber dieser hat einen Testfall, den Sie verwenden können.

@ fd0 Ich schlage vor, auch eine Option (--store-full-path) zum Sichern einzuschließen, in der explizit der vollständige "echte" Pfad des Sicherungsziels gespeichert wird.

Der Grund dafür ist, dass Sie im Fall tar und mit mehreren anderen Sicherungswerkzeugen einen kleinen verschlungenen Wiederherstellungsbaum erhalten können. Obwohl dies eine vernünftige Standardeinstellung ist, würde es mir persönlich gefallen, wenn meine Wiederherstellungen dem gesamten Layout des ursprünglichen Dateisystems für Host-Backups ähneln. (Noch besser, wenn bei der Wiederherstellung der Hostname auch dem Wiederherstellungsspeicherort vorangestellt werden könnte.)

@trbs Ich denke, die Standardeinstellung muss das Speichern vollständiger Pfade sein, mit einem Schalter für den speziellen Fall der Verwendung relativer Pfade. Grund dafür ist, dass rel-Pfade unerwartetes oder undefiniertes Verhalten hervorrufen können, abs jedoch nicht. Wenn Sie Präfixe oder eine andere Form der Pfadverwaltung anfordern möchten, würde ich vorschlagen, dass dies ein völlig anderes Problem ist.

Ich habe darüber nachgedacht und denke, wir müssen das Sicherungsverhalten ändern, damit immer der vollständige Pfad (wie in der Befehlszeile angegeben) gespeichert wird. Das macht tar und es funktioniert sehr gut. Dies ist leider ein Relikt einer schlechten Designentscheidung zu Beginn der Entwicklung für Restic.

+1 für --store-full-path

Ich hasse nur +1, aber ich bin auch sehr an einer Lösung für diesen Fehler interessiert. Habe mehrere anstehende Installationen von Restic, bei denen dieser Bug leider ein Showstopper ist.

Vielen Dank an @ fd0 für Ihre Arbeit daran. Ich verstehe, dass es jetzt nicht einfach ist, sich zu entspannen.

-1 für --store-full-path . Ich würde viel lieber sehen, dass der vollständige Pfad immer in der Sicherung verläuft und dann ein --strip-components <N> zum Entfernen von Teilen vorhanden ist, wenn Sie diese zur Wiederherstellungszeit nicht benötigen. Dies bedeutet, dass die vollständigen Daten in der Sicherung immer verfügbar sind. Wenn der Benutzer zum Zeitpunkt der Wiederherstellung zu viele Komponenten aus dem Pfad entfernt und daher Unterverzeichnisse kombiniert, wird dies zu einem behebbaren Benutzerfehler.

Das Voranstellen des Hostnamens vor dem Sicherungsspeicherort scheint über die cmdline einfach möglich zu sein, da die meisten Leute vorher wissen, von welchem ​​Host sie wiederherstellen werden :)

Angesichts der Tatsache, dass Sie noch nicht 1.0 sind, stimme ich zu, dass Sie, wenn eine wichtige Änderung vorgenommen werden muss, um die ideale Lösung zu finden, dies eher früher als später tun müssen.

@mholt Ich stimme zu, ich arbeite bereits daran. Wie gesagt, dies wird durch eine schlechte Entwurfsentscheidung frühzeitig verursacht und muss korrigiert werden.

Hey @ fd0 - habe gerade gesehen, dass 0.7 veröffentlicht wurde. Ist dies (und # 910 und # 909) auf der Karte für 0.7.1?

Vielleicht nicht für 0.7.1, sondern für 0.8.0 oder so. Ich habe aber schon angefangen daran zu arbeiten. Vielleicht ein bisschen Hintergrund: Dies wird durch den Archivierungscode verursacht, der der älteste Code ist, der in Restic vorhanden ist. Leider ist der Archivierungscode (als ich 2013/2014 gerade erst anfing zu lernen) sehr komplex und ich habe viele Anfängerfehler gemacht (zu viel Parallelität, zu viele Kanäle). Ich machte mir auch Sorgen um Dinge, die sich als überhaupt kein Problem herausstellten, und übersah Dinge, die zu einem Problem wurden (z. B. die Indexbehandlung).

Daher habe ich bereits damit begonnen, den Archivierungscode vollständig neu zu implementieren, wobei die Parallelität nur dann verwendet wird, wenn dies sinnvoll ist (dh einzelne Blöcke verarbeitet) und nicht 20 Dateien parallel von der Festplatte gelesen werden. Dieser Code enthält auch das ordnungsgemäße Gehen im Verzeichnis und fügt die vollständigen Pfade in das Repo ein.

Glücklicherweise ist dies wirklich nur der Archivierer, der berührt werden muss. Der Rest des Codes wird (dank des Designs von Restic und Repo) weiterhin einwandfrei funktionieren.

Wird sich diese Änderung auf vorhandene Repositorys auswirken und wenn ja, wie?

"Beeinflussen" in Bezug auf "Neue Backups haben eine etwas andere Struktur", ja, aber das war es auch schon. Kein migrate oder irgendetwas benötigt.

Daher wurde # 1209 zusammengeführt und verbessert die Situation, indem Namenskonflikte erkannt und gelöst werden (durch Umbenennen). Dieses Problem ist jedoch noch nicht vollständig gelöst. Ich arbeite dran :)

@ fd0 Irgendeine Idee, wann wir Schnappschüsse erwarten könnten, die den vollständigen ursprünglichen Pfad enthalten? Wir arbeiten derzeit an der Automatisierung von Backups und Wiederherstellungen mithilfe von Restic.

Bei der Automatisierung der Wiederherstellung muss der Quellpfad intakt sein.

Wenn ich einen Server mit zwei 'Daten'-Verzeichnissen habe, die gesichert werden (und dies ist nicht theoretisch, haben wir eine Reihe von Servern mit Confluence- und JIRA' Daten'-Verzeichnissen, die gesichert werden müssen) - der Wiederherstellungsprozess muss wissen, welche Datenverzeichnis gehört zu Confluence und welches Datenverzeichnis gehört zu JIRA. Ein Name wie 'data' und 'data-1' schneidet hier offensichtlich nicht.

Ich denke, die beste Lösung für den Moment besteht darin, die Datenverzeichnisse in separaten Snapshots zu sichern und sie mit "JIRA" oder "Confluence" zu kennzeichnen.

Es gibt keine Zeitleiste, sorry.

Ich denke, die beste Lösung für den Moment besteht darin, die Datenverzeichnisse in separaten Snapshots zu sichern und sie mit "JIRA" oder "Confluence" zu kennzeichnen.

Ja, aber gemäß # 1225 können Sie sie später nicht einfach zu einem Repo zusammenführen.

In Bezug auf die Option --store-full-path : rsync gibt es diese Option: -R , --relative .
Vielleicht den gleichen Optionsnamen für Restic verwenden?

Für vollständige Systemsicherungen habe ich hier eine Problemumgehung beschrieben: https://forum.restic.net/t/full-system-restore/126/8 Es ist nicht schön, wird aber die Arbeit erledigen, bis # 1494 fertig ist.

Dieser Fehler hat mich ein wenig beunruhigt, aber ich kann ihn in 0.8.3 mit den angegebenen Schritten nicht reproduzieren. Ist das noch ein offenes Thema?

Ja, leider ist dies immer noch ein Problem.

Hm, ich kann das Problem irgendwie nicht replizieren, bin mir also nicht sicher, was ich anders mache. Ich habe mein Testskript angehängt.

test_restic_549.zip

Sie können es so reproduzieren:

$ mkdir dir1/subdir
$ echo foo > dir1/subdir/foo

$ mkdir dir2/subdir
$ echo bar > dir2/subdir/bar

$ restic backup dir1/subdir dir2/subdir
password is correct
scan [/home/user/dir1/subdir /home/user/dir2/subdir]
scanned 2 directories, 2 files in 0:00
/home/user/dir2: name collision for "subdir", renaming to "subdir-1"
[...]
snapshot f6138d06 saved

Für die beiden Unterverzeichnisse verwendet restic den Basisnamen des Unterverzeichnisses als oberstes Verzeichnis im Repo. Für dir1/subdir und dir2/subdir es also beide subdir die Kollision.

Das Auflisten des neuesten Schnappschusses zeigt Folgendes:

$ restic ls latest
password is correct
snapshot f6138d06 of [/home/user/dir1/subdir /home/user/dir2/subdir] at 2018-03-21 20:38:33.58232292 +0100 CET):
/subdir
/subdir/foo
/subdir-1
/subdir-1/bar

In Ihrem Testfall sind die Basisnamen von $TESTDIR/dir1 und $TESTDIR/dir2 unterschiedlich ( dir1 vs. dir2 ), sodass der Fehler nicht auftritt.

Aus den Versionshinweisen von Version 0.9:

Die erste Sicherung mit dieser Version von restic führt wahrscheinlich dazu, dass alle Dateien lokal erneut gelesen werden, sodass es viel länger dauert. Das nächste Backup danach wird wieder schnell sein.

Ich möchte Ihnen nur einige Statistiken geben:

erste Sicherung:

-------------------------------------------------------------
Start: Do 24. Mai 05:15:01 CEST 2018
437 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:38
snapshot f724ff21 saved

Files:         556 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 556 files, 914.493 GiB in 2:15:29
snapshot 3c0e0f1b saved

Files:       11570 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 11570 files, 66.044 GiB in 16:21
snapshot 312fd29c saved

Files:        2309 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 2309 files, 163.332 GiB in 24:13
snapshot 2baab573 saved

Files:         312 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 312 files, 1.503 TiB in 4:48:23
snapshot 02dfe40c saved

Files:       743172 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      84.927 MiB

processed 743172 files, 89.131 GiB in 2:48:59
snapshot dcee3e70 saved

Files:         441 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 441 files, 727.575 GiB in 1:56:36
snapshot 676adc45 saved
End:   Do 24. Mai 17:46:46 CEST 2018
Duration: 12h:31m:45s
-------------------------------------------------------------

der zweite:

-------------------------------------------------------------
Start: Fr 25. Mai 05:15:01 CEST 2018
444 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:42
snapshot 9c7cf320 saved

Files:           0 new,     0 changed,   556 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 556 files, 914.493 GiB in 0:15
snapshot 533e2155 saved

Files:           0 new,     0 changed, 11570 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 11570 files, 66.044 GiB in 0:17
snapshot 1c1235c3 saved

Files:           0 new,     0 changed,  2309 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 2309 files, 163.332 GiB in 0:13
snapshot d5ef168d saved

Files:           0 new,     0 changed,   312 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 312 files, 1.503 TiB in 0:16
snapshot 76e94946 saved

Files:         292 new,     0 changed, 743172 unmodified
Dirs:            0 new,     2 changed,     0 unmodified
Added:      32.790 MiB

processed 743464 files, 89.163 GiB in 1:06
snapshot 12fa66e8 saved

Files:           0 new,     0 changed,   441 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 441 files, 727.575 GiB in 0:15
snapshot ab2d29bb saved
End:   Fr 25. Mai 05:19:12 CEST 2018
Duration: 0h:4m:11s
-------------------------------------------------------------

also viel länger, bedeutet viel länger :-)
Mach weiter so! 👍

@ fd0 , tolle Arbeit! Vielen Dank! Ihr Backup-Tool ist mein Favorit für alle meine Off-Site-Backups (mit b2) :-)