buntspechtklopfen
Anmeldungsdatum: 21. Oktober 2021
Beiträge: 27
|
Hallo zusammen, System: 20.04.3, Kernel 5.13.0-28 x86_64 Mate 1.24.0 Speichermedium lokale 2TB-USB-Festplatte nun habe ich ein kleines Problem nach einem Festplattenfehler. Beim Versuch alles wiederherzustellen, funktioniert die Wiederherstellung mit Deja-Dup nicht. Ich kann alles wunderbar eingeben, dann werde ich vor der Wiederherstellung nach einem Passwort gefragt (siehe Anhang). Dort kann ich entweder das admin-Passwort oder die Passphrase der Verschlüsselung eingeben. Es passiert nix.
Wenn ich Deja-Dup schon als sudoer starte, kommt direkt die Fehlermeldung: Traceback (innermost last):
File "/usr/bin/duplicity", line 106, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 92, in with_tempdir
fn()
File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1525, in main
action = commandline.ProcessCommandLine(sys.argv[1:])
File "/usr/lib/python3/dist-packages/duplicity/commandline.py", line 1175, in ProcessCommandLine
globals.backend = backend.get_backend(args[0])
File "/usr/lib/python3/dist-packages/duplicity/backend.py", line 225, in get_backend
obj = get_backend_object(url_string)
File "/usr/lib/python3/dist-packages/duplicity/backend.py", line 211, in get_backend_object
return factory(pu)
File "/usr/lib/python3/dist-packages/duplicity/backends/giobackend.py", line 82, in __init__
ensure_dbus()
File "/usr/lib/python3/dist-packages/duplicity/backends/giobackend.py", line 37, in ensure_dbus
output = p.communicate()[0].decode("utf8", errors="replace")
AttributeError: 'str' object has no attribute 'decode' Irgendwas scheint mit der Entschlüsselung nicht zu funktionieren. Wenn ich nun die Hilfe lese, kann ich die Daten entschlüsseln und kopieren. Aber nicht nutzen, da ja die Daten inkrementell gesichert werden. Deswegen sind genau die wichtigen Daten nicht so einfach wiederherzustellen. Laut Anleitung geht das wohl mit rdiff patch ... Doch das verstehe ich nicht. Wie soll ich das machen? Gibt es dazu Beispiele? Ich habe ein paar hundert Ordner mit dem gewünschten Dateinamen und darin jeweils einer Datei '1' und '2'. Hat jemand einen Tipp, wie ich die Deja-Dup-Wiederherstellung doch noch zum Laufen bekomme oder wie ich die Dateien wieder zusammensetzen kann? Danke vorab,
schöne Grüße
buntspechtklopfen
- Bilder
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3380
|
Hallo buntspechtklopfen, vielleicht hilft dir das hier weiter: Archiv/Howto/Manuelle Wiederherstellung für Déjà Dup. Das ist zwar mangels aktuellen Tests im Archiv könnte aber noch funktionieren.
Ich habe nochmal nachgedacht und das ist wohl nicht hilfreich. Du willst ja an die inkrementelle Sicherung.
Was genau geht denn noch und was nicht? Also welcher Anleitung bist du gefolgt und hast dabei welche Befehle eingegeben? Hast du schon versucht duplicity direkt zu verwenden? Ich weiß gerade nicht so genau wo du stehst. Vej
|
buntspechtklopfen
(Themenstarter)
Anmeldungsdatum: 21. Oktober 2021
Beiträge: 27
|
N'Abend Vej, danke für die Antwort. Vej schrieb:
Was genau geht denn noch und was nicht? Also welcher Anleitung bist du gefolgt und hast dabei welche Befehle eingegeben? Hast du schon versucht duplicity direkt zu verwenden? Ich weiß gerade nicht so genau wo du stehst.
Ich habe in der Hilfe für Deja-Dup 'Hilfe zu Datensicherungen › Wiederherstellen von Dateien »
Falls alles schiefgehen sollte >>> Manuelles Wiederherstellen' geschaut. Zuerst habe ich über das Terminal versucht mit duplicity wiederherzustellen. duplicity --gio file:///media/backup /tmp/restore Das erzeugte den gleichen Fehler. Dann werden in der Hilfe weiterhin folgende Befehle für meinen Fall aufgeführt:
Zum Entschlüsseln
gpg --multifile --decrypt duplicity-full.20110127T131352Z.*.difftar.gpg ,
dann zum Umwandeln in 'normale' Dateien
for t in duplicity-full.20110127T131352Z.*.difftar; do tar xf $t; done .
Dann steht dort noch lapidar Nun befinden sich die Patch-Dateien in den Ordnern multivolume_snapshot und snapshot. Jede Datei, die über mehrere Medien verteilt war, wird in multivolume_snapshot sein. Angenommen, Sie haben die Datei /home/jane/essay.txt gesichert:
cd multivolume_snapshot/home/jane/essay.txt
cat * > essay.txt Um Daten von inkrementellen Datensicherungen wiederherzustellen, benutzen Sie rdiff, um die Dateien zusammenzusetzen. Für Informationen zum Aufruf siehe man rdiff.
Und das bringt mich nun an meine Grenzen. Auch die manpage erläutert nicht wirklich, was da passiert und wie das gehen soll, ein Beispiel fehlt. Da weiß ich nicht weiter. Schöne Grüße
buntspechtklopfen
|
buntspechtklopfen
(Themenstarter)
Anmeldungsdatum: 21. Oktober 2021
Beiträge: 27
|
eben habe ich noch rumgetestet und herausgefunden, dass die Zeile
cat * > dateiname.end tatsächlich funktioniert. Aufgerufen aus dem Ordner mit dem Dateinamen, der gleich wie die fehelnde Datei heißt, die aus den Schnipseln in dem Ordner zusammengesetzt werden muss. Allerdings: Es sind mehrere 100 oder gar über 1000 Ordner. Das für alle Ordner einzeln aufzurufen ist natürlich Quark. Aber gut, an die wichtigsten Dateien komme ich so nun ran. Was noch fehlt ist jetzt der Hinweis zu rdiff, der wohl automatisiert diesen Schritt einem abnehmen könnte. Wenn es dazu eine verständliche Anleitung gäbe, wäre das super. Auch auf engl. Gute Nacht sagt
buntspechtklopfen
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3380
|
Hallo buntspechtklopfen. Das Zusammensetzen mit cat nimmt rdiff dir nicht ab. rdiff kommt später. Mit cat setzt du nur bei dem Vollbackup (mit "duplicity-full" im Namen) ganze Dateien zusammen. Bei den Inkrementellen Sicherungen wird nur die Änderung gesichert. Hast du also einen älteren Stand einer Datei (file.txt) mit cat zusammengesetzt und auch die Datei mit den Änderungen (file_patch.txt) aus dem inkrementellen Backup liegt vor (muss ggf. auch mit cat zusammengesetzt werden falls die Änderungen groß genug waren), so kannst du nun file.txt mit dem Befehl rdiff patch file.txt file_patch.txt file_neu.txt zu file_neu.txt aktualisieren. Das musst du für jede Datei die du retten möchtest einmal für jedes inkrementelle Backup machen. Weil das wie du schon bemerkt hast viel Aufwand ist, eignet sich das so eher zum Wiederherstellen einzelner Dateien. Was ich mich bei deinem ursprünglichen Problem frage, ist warum du überhaupt Adminrechte benötigst. Normalerweise sollte Déjà Dup keine Adminrechte benötigen. Oder hast du Orte außerhalb deines Homeverzeichnis gesichert? Viel Erfolg Vej
|
buntspechtklopfen
(Themenstarter)
Anmeldungsdatum: 21. Oktober 2021
Beiträge: 27
|
Moin Vej, vielen Dank für die Tipps.
Mit einem kleinen Skript konnte ich nun die "voll"-Dateien zusammensetzen. Dann ist der nächste Schritt, die inc-Dateien dazuzupacken. Das werde ich die Tage versuchen und schauen, ob sich daraus ein vernünftiges Skript ergibt, das ich hier online stellen könnte.
Skript soweit, Aufruf aus dem Ordner, in dem die Ordner mit den Dateinamen liegen. Diese Ordner werden damit durch die eigentlichen Dateien ersetzt:
1
2
3
4
5
6
7
8
9
10
11
12 | #!/bin/bash
for folder in ./*/ ; do
fname=${folder#*/}
realfname=${fname%/}
cd "$realfname"
dir
cat * > "$realfname"
cd ..
mv -v "./$realfname/$realfname" "$realfname.tmp"
rm -drv "$realfname"
mv -v "$realfname.tmp" "$realfname"
done
|
Die -v-Optionen sind natürlich nicht erforderlich. Schöne Grüße
buntspechtklopfen P.S. root brauche ich, weil ich eine Datentausch-Platte win-Linux nicht im home-Verzeichnis eingebunden habe, sondern auf /windows/...
|
buntspechtklopfen
(Themenstarter)
Anmeldungsdatum: 21. Oktober 2021
Beiträge: 27
|
Mit Deinen Tipps bin ich schon auf einem ganz guten Weg, danke dafür! Ich habe die folgenden Ordner erhalten:
snapshot (normale, lesbare Dateien), multivol_snapshot (Dateischnipsel, müssen zusammengesetzt werden, dann lesbar), diff ("normale" Dateien, zu klein und nicht lesbar) und multivol_diff (Dateischnipsel, müssen zusammengesetzt werden, dann wie diff).
Das Zusammensetzen der inkrementellen Sicherung hat auch schon geklappt. Das würde ich eigentlich so verstehen: Mit rdiff patch werden 'snapshot' und 'diff' zusammengesetzt (wobei sich hier etliche Dateien nicht zu überschneiden scheinen?) und ebenso die beiden multivol_*-Ordner. Doch habe ich als Beispiel eine aktuellere, neuere Dateien in den Ordnern 'diff' und 'multivol_snapshot'. Und es scheint auch so zu sein, dass aus den inc-Dateien ebenfalls in snapshot geschrieben wurde, nicht nur in diff, anzunehmen wäre das für neue Dateien - wobei das teilweise nicht stimmt. Vielleicht weil der Rechner vor Abschluss der ersten Sicherung abgeschaltet wurde? Da kann ich mich nicht mehr erinnern, das wäre nicht auszuschließen. Deswegen zur Sicherheit noch folgende Frage:
In welcher Reihenfolge muss ich Dateien aus welchen Ordnern zusammen setzen? Schöne Grüße
buntspechtklopfen Bearbeitet von Vej: \[mark\] ist für Hervorhebungen in Codeblöcken gedacht (vgl.Forum/Syntax). Für Fließtext bitte einfach fett benutzen. Danke!
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3380
|
Hallo buntspechtklopfen. Verstehe ich das richtig, dass du die Vollsicherung und mehrere inkrementelle Sicherungen auf einer Ordnerebene entpackt hast, sodass du nur je einmal über snapshot, multivol_snapshot, diff und multivol_diff verfügst? Falls dem so ist, würde ich das an deiner Stelle ändern, auch wenn es bedeutet, dass du die letzten Schritte leider nochmal machen musst. Was ich haben wollte wäre diese Struktur (die Daten für die inkrementellen Sicherungen habe ich mir ausgedacht): duplicity-full.20110127/ snapshot multivol_snapshot
duplicity-inc.20110215/ snapshot multivol_snapshot diff multivol_diff
duplicity-inc.20110301/ snapshot multivol_snapshot diff multivol_diff
Wenn das jetzt richtig verstanden habe (ich habe das noch nie selber gemacht), dann verwendest du dein Skript um die Dateien in den Ordnern *_multivol zusammenzusetzen und kopierst sie in die entsprechenden Ordner (diff, snapshot). Die *_multivol können dann weg und wir haben noch duplicity-full.20110127/ duplicity-inc.20110215/ duplicity-inc.20110301/
Jetzt müsstest du (oder vielleicht ein Skript) alle Dateien aus duplicity-full.20110127/snapshot nehmen, mit duplicity-inc.20110215/diff aktualisieren duplicity-inc.20110215/snapshot dazu kopieren, mit duplicity-inc.20110301/diff aktualisieren und duplicity-inc.20110301/snapshot dazu kopieren. Das funktioniert nur mit Sicherungen die sich in einer "Sicherungskette" befinden, d.h. die nach einer Vollsicherung erfolgt sind, ohne dass es eine neuere Vollsicherung gibt. Die Vollsicherungen sollten alle Dateien zum Sicherungszeitpunkt enthalten. Lass mich bitte wissen ob das klappt. Alles Gute Vej
|
buntspechtklopfen
(Themenstarter)
Anmeldungsdatum: 21. Oktober 2021
Beiträge: 27
|
Moin Vej, danke für Deine Unterstützung! Du hast das vollkommen richtig verstanden. Nun mache ich mich also dran, und versuche das so zusammenzusetzen, wie Du beschreibst. Ich bin gespannt. Und je nach Erfolg werde ich entsprechende Skripte hier dann online stellen. Auf jeden Fall berichte ich vom Ergebnis. Das kann etwas dauern, die normale Arbeit lässt mir diese Woche wenig Zeit leider. Schöne Grüße
buntspechtklopfen
|
juribel
Anmeldungsdatum: 20. April 2014
Beiträge: 856
|
Hallo, Nur meine 2 Cents, denn wenn ich diesen Thread lese, kann ich meine Finger nicht still halten... Wenn ich das richtig verstanden habe, legt Deja-Dup eine Vollsicherung und dann darauf aufbauend inkrementelle Sicherungen an. Das finde ich schon mal sehr windig. Da darf nun wirklich nichts kaputt gehen. Und dann benutzt Deja-Dup duplicity. Auf deren Homepage steht sinngemäß "...is a fairly mature system", also mit meinen Worten, "halbwegs ausgereift". Für mich sind das gleich zwei KO-Kriterien, und meine Daten würde ich solchen Tools keineswegs anvertrauen. Also Finger von weg!! Statt dessen gibt es hier im Wiki wunderbare Shell-Skripte, die mit rsync und Hardlinks arbeiten. Da gibt es zwar keine bunten Knöpfchen zum Hin- und Her-Schieben, und es gibt auch keine dicken Plus- und Minus-Tasten wie im Spielzeugladen, und ja, man muss es manuell aufrufen, aber es FUNKTIONIERT. Die Skripte legen für jeden Tag der Datensicherung auf dem Zielmedium einen Datums-Ordner an, der alle zu sichernden Ordner und Dateien als Hard links enthält. Nur geänderte und neue Ordner/Dateien werden "echt" kopiert und gelöschte werden gelöscht. Dadurch sind die Sicherungen inkrementell, beruhen aber nicht aufeinander. Selbst wenn man mittendrin versehentlich einen Sicherungsordner löschen sollte, kann nichts passieren. DAS ist für mich DatenSICHERUNG! Und braucht wenig Platz, und geht schnell. Viele freundliche Grüsse, juribel
|
buntspechtklopfen
(Themenstarter)
Anmeldungsdatum: 21. Oktober 2021
Beiträge: 27
|
N'Abend Juribel, danke für die Hinweise! Das Programm "Datensicherung" bei Mate ist eben ein umbenanntes Déja-Dup. Insofern wollte ich das ausprobieren. War leider nicht besonders erfolgreich. Da ich relativer Neuling mit Ubuntu bin, habe ich noch keine rsync-Anleitung gefunden, mit der ich mich getraut hätte, meine Daten zu sichern. So langsam taste ich mich nun zwangsweise da ran. juribel schrieb: Statt dessen gibt es hier im Wiki wunderbare Shell-Skripte, die mit rsync und Hardlinks arbeiten.
Meinst Du hier noch andere als die beiden rsync und 'Skripte/Backup mit RSYNC'? Für Tipps bin ich immer offen. Weil mit Back-in-Time bin ich auch nicht 100% zufrieden, das frisst zu viel Platz. Und deswegen muss ich ohnehin irgendwann auf rsync umsteigen. Die Lernhürden sind allerdings da. https://forum.ubuntuusers.de/post/9282453/ - das ist meine aktuelle Konfiguration. Gute Nacht buntspechtklopfen
|
juribel
Anmeldungsdatum: 20. April 2014
Beiträge: 856
|
Guten Morgen, ja, genau dies meine ich, vor allem 'Skripte/Backup mit RSYNC' und zwar das Skript in dem Kapitel "Das Skript". Ich selbst habe ein ähnliches Skript, wobei ich leider nicht mehr weiss, woher die Modifikationen kommen. Es tut bei mir aber seit über 10 Jahren klaglos seinen Dienst, vor allem auch beim Zurücksichern, weil hierfür nichts weiter benötigt wird als die Bordmittel der Dateimanager. Kann sein, dass mein Skript in einer früheren Version des Wiki-Artikels beschrieben wurde. Es fehlt der Mechanismus des monatlichen Rotierens, den ich ohnehin nicht gut finde. Zu alte Sicherungen lösche ich lieber ab und zu von Hand Ich würde dir vorschlagen, zunächst mit dem Skript aus dem Wiki zu experimentieren, und zwar über mehrere Tage hinweg. Das Einzige, was man in dem Skript vor dem ersten Start tun muss, ist, in den Umgebungsvariablen SOURCES und TARGET Quelle(n) und Ziel festzulegen (dürfen natürlich jederzeit geändert werden). Wenn du möchtest, kann ich dir auch ggf. gerne meine Variante schicken, und meine Aliase zum bequemeren Aufrufen und Beobachten der Sicherung. Ist dir der Mechanismus "hard link" bekannt? Viele freundliche Grüsse, juribel EDIT: Im Wiki kann man noch ältere Versionen der Artikel abrufen. Mein Skript war unter "Das Skript" in der Version des Artikels vom 10.03.2011 beschrieben worden. Das war damals die Quelle für meine Version des Backup-Skripts und ist dort auch heute noch abrufbar.
|
buntspechtklopfen
(Themenstarter)
Anmeldungsdatum: 21. Oktober 2021
Beiträge: 27
|
Hallo zusammen, jetzt endlich ein Feed-back: Das Zusammensetzen der Dateien funktioniert halbwegs. Von 5 händischen Versuchen der wichtigsten Dateien habe ich 4 wiederhergestellt bekommen. Ohne größere Prüfung, scheint der Inhalt zu passen. Bei einer LibreCalc-Datei funktioniert das Zusammensetzen (noch?) nicht. Ein Zwischenstand ging noch zu rekonstruieren. Alle neuen Dateien scheinen auch wiederherstellbar zu sein. Merkwürdig ist, dass die letzten beiden Sicherungen für alle bis dahin vorhandenen Dateien im Diff-Ordner kleine (Änderungs-?)-Dateien enthalten, die jedoch keine tatsächliche Dateiveränderung beinhalten. Der Versuch, diese wiederherzustellen ist zwar erfolgreich, in den getesteten Fällen jedoch nicht notwendig, es gab keine weitere Änderung. Der Rest ist jetzt erstmal nicht so wichtig und ich hoffe, dass es im fraglichen Zeitraum keine relevanten Änderungen gab. Falls doch müsste ich diese letzten Schnipsel noch überspielen. Also herzlichen Dank an Vej, die Tipps waren richtig! Ein weiteres Skript habe ich jetzt allerdings (noch) nicht erstellt. Ich hoffe, es erübrigt sich. Dieses Thema des Titels ist damit gelöst. Das rsync-Thema gehört eigentlich an eine andere Stelle. Kurz dazu: @juribel: Mit dem rsync-Skript als Alternative bin ich jetzt noch nicht relevant weiter, da ich erstmal die Daten wiederherstellen musste, bevor ich noch mehr Datenmüll produziere. Ich habe mir die beiden Version des Skripts mal gesichert und werde mir das in Ruhe anschauen. Das mit den harten Links ist mir klar. Der Nachteil: Man kann mit dem einfachen "Eigenschaften"-Check des Ordners nicht heraus finden, wie viel Speicher eine Sicherung tatsächlich belegt. Das Löschen einer alten Sicherung gibt jedenfalls weniger frei, als man hofft. Besten Dank nochmals und schöne Grüße
von buntspechtklopfen
|