
Kann mir jemand dabei helfen? Ich verwende seit einiger Zeit Deja-Dup, um mein Ubuntu 14.04-Gerät zu sichern. Ich habe Duplicity Version 0.6.23, Deja-Dup Version 30.0. Egal, welches Backup ich auswähle, ich erhalte Fehler.
Wenn ich die Déjà-vu-Benutzeroberfläche verwende, erhalte ich lediglich diesen Fehler: "BackendException: Error listng s3+http
[Ich setze ein Leerzeichen dazwischen, weil ich keinen Link posten kann] ://mybucketname1/computer-XPS13-9333"
(zum Posten anonymisiere ich alle identifizierenden Informationen in Fehlermeldungen und Befehlen)
Ich habe mit Duplicity ein paar Varianten über die Befehlszeile ausprobiert, aber ohne Erfolg.
Dieser Befehl:
AWS_ACCESS_KEY_ID=XXXXXXXX AWS_SECRET_ACCESS_KEY=XXXXXXX duplicity restore s3+http
[Ich setze hier ein Leerzeichen, weil ich sonst keinen Link posten kann] ://mybucketname1/computer-XPS13-9333 /media/standard/Seagate\ Backup\ Plus\ Drive/restore/
gibt diesen Fehler zurück:
PermanentRedirect The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.</Message><Bucket>mybucketname1</Bucket><Endpoint>mybucketname1.s3.amazonaws.com</Endpoint><RequestId>XXXXXXXX</RequestId><HostId>Pwl/XXXXXXXXXXXXXXXXXXXXXXXX=</HostId></Error>
Also habe ich es mit einem anderen Endpunkt versucht und Folgendes ausgeführt:
AWS_ACCESS_KEY_ID=XXXXXXXXX AWS_SECRET_ACCESS_KEY=XXXXXXXXX duplicity restore s3+http
[I'm putting a space heere because it won't let me post a link]
://mybucketname1.s3.amazonaws.com/computer-XPS13-9333 /media/standard/Seagate\ Backup\ Plus\ Drive/restore/
<Error><Code>NoSuchBucket</Code><Message>The specified bucket does not exist</Message><BucketName>mybucketname1.s3.amazonaws.com</BucketName><RequestId>XXXXXXXXX</RequestId><HostId>XXXXXXXXXXXXXXX</HostId></Error>
Ich dachte, dass der Endpunkt, den es mir anzeigte, vielleicht falsch war, also probierte ich aus, was ich auf der S3-Site fand und führte Folgendes aus:
AWS_ACCESS_KEY_ID=XXXXXXXX AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXX duplicity restore s3+https
[I'm putting a space bere because it won't let me post a link]
://s3-us-west-2.amazonaws.com/mybucket1/computer-XPS13-9333 /media/standard/Seagate\ Backup\ Plus\ Drive/restore/
und habe diesen Fehler erhalten:
UnsupportedBackendScheme: scheme not supported in url: s3
Ich dachte, dies könnte ein http/https-Problem sein, also habe ich denselben Befehl wie http ausprobiert und diesen Fehler erhalten, aber ich bin ziemlich sicher, dass dieser Endpunkt keine echte URL ist, die ich verwenden sollte:
PermanentRedirect
Der Bucket, auf den Sie zugreifen möchten, muss über den angegebenen Endpunkt angesprochen werden. Bitte senden Sie alle zukünftigen Anfragen an diesen Endpunkt.s3-us-west-2.amazonaws.coms3-us-west-2.amazonaws.com.s3.amazonaws.comXXXXXXXXXXXXXXXXXXXXX
Hat jemand Empfehlungen? Ich habe eine Menge Daten verloren und hoffe, sie zurückzubekommen und stattdessen mit Dropbox oder so etwas zu sichern. Ich habe dieses Problem schon eine Weile untersucht und anscheinend hat Duplicity alle möglichen Probleme, aber ich habe noch keine Lösung dafür gefunden.
Antwort1
Ich habe das herausgefunden und beantworte meine eigenen Fragen zum Nutzen aller anderen mit ähnlichen Problemen. Zuerst habe ich festgestellt, dass ich nicht ein ganzes Backup auf einmal wiederherstellen kann. Es ist einfach zu groß und läuft ab. Die Strategie, die ich anwenden musste, war, Unterverzeichnisse auf einmal zu bearbeiten. Außerdem wurde nichts zurückgegeben, als ich versuchte, aktuelle Dateien aufzulisten. Obwohl die Backupdateien riesig waren, hieß es, ich hätte keine Dateien zum Wiederherstellen. Ich habe herausgefunden, dass -t
es funktionieren würde, wenn ich das Flag verwende. Das bedeutet wahrscheinlich, dass mein letztes Backup beschädigt war, aber indem ich etwas zurück in die Vergangenheit geschaut habe (in meinem Fall 6 Monate), konnte es einige Dateien zum Wiederherstellen finden. Zuerst musste ich diese Dateiliste abrufen, damit ich wusste, welche Dateien wiederhergestellt werden mussten:
AWS_ACCESS_KEY_ID=xxxxxxxxxxxxxxx AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxx PASSPHRASE=xxxxxxxxx duplicity list-current-files --timeout=2400 --tempdir /path/path/path/ --num-retries=500 -t 6M s3://s3-us-west-2.amazonaws.com/mybucketname1/computer-name | tee -a restore_file_list-6M.txt
Dadurch erhalten Sie eine Datei restore_file_list-6M.txt
, die Sie verwenden müssen, um herauszufinden, welche Dateien sich in Ihrem Backup befinden.
Sie werden auch feststellen, dass trotz der Angaben in der Dokumentation das s3+http://
falsch ist und Sie s3://
stattdessen Folgendes möchten.
Nachdem ich die Liste der Dateien im Backup sortiert hatte restore_file_list-6M.txt
, konnte ich sie mit diesem Befehl Verzeichnis für Verzeichnis wiederherstellen:
AWS_ACCESS_KEY_ID=XXXXXXXXXXX AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXX PASSPHRASE=XXXXXXXXXXXX duplicity restore --timeout=2400 --tempdir /path/path/path/ --allow-source-mismatch --file-to-restore source/in/backup --num-retries=500 -t 6M s3://s3-us-west-2.amazonaws.com/mybucketname1/computer-name /place/I/want/to/restore/to/
Ich weiß nicht, ob das Flag --timeout irgendeine Funktion hatte, aber --num-retries ist auf jeden Fall wichtig, da es ungefähr einmal pro Datei zu einer Zeitüberschreitung kommt und es manchmal über hundert Mal zu einer Zeitüberschreitung kommt, bevor eine Datei erfolgreich heruntergeladen wird.
Nun habe ich für immer mit der Doppelzüngigkeit abgeschlossen.