AndreasMu
Anmeldungsdatum: 8. August 2014
Beiträge: 30
|
Hallo zusammen, ich sichere meinen Server seit Monaten schon mit Duply, freue mich täglich über positive Mails dass das Backup (monatlich full, täglich inkrementiell) gelaufen ist.
Seit ein paar Tagen aber geht es nicht mehr und ich bekomme Fehlermeldungen, wo ich nicht weiterkomme.
An einem Tag steht im Duply Log folgendes, seitdem geht nichts mehr:
ERROR 31 GPGError
. GPGError: GPG Failed, see log below:
. ===== Begin GnuPG log =====
. gpg: keyring `/root/.gnupg/secring.gpg' created
. gpg: keyring `/root/.gnupg/pubring.gpg' created
. gpg: encrypted with ELG-E key, ID xxx
. gpg: decryption failed: secret key not available
. ===== End GnuPG log =====
Ich habe nichts am Server verändert, auch sind in meinem duply-Verzeichnis der sec und der pub key vorhanden... wie kann ich vorgehen?
Braucht ihr noch weitere Infos? Besten Dank! Andy
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3390
|
Hallo AndreasMu, nutzt du duplicity und benutzt Duply als Abkürzung, oder ist das ein anderes Backupprogramm, das wirklich Duply heißt? Viele Grüße Vej
|
unbuntuS12
Anmeldungsdatum: 2. Juni 2010
Beiträge: 1816
|
@Vej: Letzteres. Duplicity ist so ein Tool, das man eigentlich ohne eigens drumrumgebasteltes Skript überhaupt nicht verwenden kann, weil es keine sinnvolle Konfigurationsdatei hat. Nachdem ich mir dann auch selber mal so ein Skript geschrieben habe, das immer größer geworden ist, habe ich dann gemerkt, dass ich nicht der erste war. Duply also in der Tat ein Wrapper.
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3390
|
Hallo. unbuntuS12 schrieb: Duply also in der Tat ein Wrapper.
Ah okay, kannte ich bisher nicht. Mal sehen, ob ich trotzdem etwas beitragen kann: duplicity verschlüsselt ja mit GnuPG. Da dessen Verschlüsselung auf einem sog. Public-Key Verfahren basiert, muss sowohl ein öffentlicher, als auch ein privater Schlüssel existieren, da algorithmusbedingt mit dem privaten Schlüssel verschlüsselte Dateien nur mit dem öffentlichen entschlüsselt werden können und umgekehrt. (Der Vollständigkeit halber: Der öffentliche Schlüssel enthält immer auch den Privaten. Der alleine reicht also auch, weil er eben beide Informationen enthält). Für eine Backupanwendung ist das nicht so toll, da hier ja eigentlich der gleiche Anwender die Dateien verschlüsselt und auch die Entschlüsselung vornimmt. Das bedeutet nun, dass der private Schlüssel für die Sicherung benötigt wird. Dieser wird laut http://duply.net/ von Duply aus dem Schlüsselring entnommen. Deshalb die Preisfrage: Ist der Schlüssel in dem Schlüsselring vorhanden oder nicht? Um das herauszufinden, müssen wir wissen, welcher Schlüsselbund verwendet wird. Wenn das jemand weiß bitte melden ☺. Ich habe mir dazu eben einmal den Quellcode von Duply durchgelesen, aber so spontan nicht die relevante Stelle gefunden. @AndreasMu: Kannst du vor der angegebenen Stelle noch etwas mehr Inhalt der Logdatei liefern? Oder ist das der Anfang? Viele Grüße Vej
|
AndreasMu
(Themenstarter)
Anmeldungsdatum: 8. August 2014
Beiträge: 30
|
Hallo Vej, danke dass Du Dich da so um mich kümmerst, ich wäre jetzt schon aufgeschmissen ☺ Ich habe hier mal die Ausgabe eines Versuchs für ein neues Fullbackup: root@vmd7708:/usr/bin# duply s3complete full
Start duply v1.8.0, time is 2015-08-30 09:45:06.
Using profile '/etc/duply/s3complete'.
Using installed duplicity version 0.6.23, python 2.7.8, gpg 1.4.16 (Home: ~/.gnupg), awk 'mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan', bash '4.3.30(1)-release (x86_64-pc-linux-gnu)'.
Encryption public key '5BE9CED8' not found.
Import keyfile '/etc/duply/s3complete/gpgkey.5BE9CED8.pub.asc' to keyring (OK)
Import keyfile '/etc/duply/s3complete/gpgkey.5BE9CED8.sec.asc' to keyring (OK)
Autoset trust of key '5BE9CED8'to ultimate (OK)
Autoset found secret key of first GPG_KEY entry '5BE9CED8' for signing.
Test - Encrypt to 5BE9CED8 & Sign with 5BE9CED8 (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.20889.1440920706_*'(OK)
--- Start running command FULL at 09:45:07.093 ---
Reading globbing filelist /etc/duply/s3complete/exclude
Synchronizing remote metadata to local cache...
Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-full-signatures.20150403T074544Z.sigtar.mp4 (not authoritative at backend).
Copying duplicity-full-signatures.20150403T074544Z.sigtar.gpg to local cache.
Copying duplicity-full-signatures.20150503T150004Z.sigtar.gpg to local cache.
Copying duplicity-full-signatures.20150603T150017Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: encrypted with ELG-E key, ID F0B37321
gpg: decryption failed: secret key not available
===== End GnuPG log =====
09:46:38.277 Task 'FULL' failed with exit code '31'.
--- Finished state FAILED 'code 31' at 09:46:38.277 - Runtime 00:01:31.183 ---
Was für mich komisch ist, dass da ein ELG-E key in der GPG Sektion auftaucht, der unterschiedlich zu dem von mir verwendeten ist. Gehört das so?
|
AndreasMu
(Themenstarter)
Anmeldungsdatum: 8. August 2014
Beiträge: 30
|
Anscheinend ist da irgendwas mit dem backup-set korrupt, ich weiß aber auch nicht wie ich es wieder anstarten könnte...
ein "cleanup" brachte den gleichen Fehler.
|
AndreasMu
(Themenstarter)
Anmeldungsdatum: 8. August 2014
Beiträge: 30
|
Also irgendwas passt da mit den Metadaten nicht, sonst stand immer in den Logs:
Local and Remote metadata are synchronized, no sync needed.
Am 24.8. dann:
NOTICE 1
. Synchronizing remote metadata to local cache...
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-full-signatures.20150403T074544Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150403T074544Z.to.20150403T150002Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150403T150002Z.to.20150404T150004Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150418T150004Z.to.20150419T150005Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150424T150008Z.to.20150425T150005Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150425T150005Z.to.20150426T150004Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150430T150004Z.to.20150501T150005Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150506T150004Z.to.20150507T150006Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150507T150006Z.to.20150508T150005Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150509T150005Z.to.20150510T150005Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150516T150005Z.to.20150517T150007Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
[das geht jetzt noch eine Weile so...]
OTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-new-signatures.20150821T150005Z.to.20150822T150004Z.sigtar.mp4 (not authoritative at backend).
NOTICE 1
. Copying duplicity-full-signatures.20150403T074544Z.sigtar.gpg to local cache.
NOTICE 1
. Copying duplicity-full-signatures.20150503T150004Z.sigtar.gpg to local cache.
NOTICE 1
. Copying duplicity-full-signatures.20150603T150017Z.sigtar.gpg to local cache.
ERROR 31 GPGError
. GPGError: GPG Failed, see log below:
. ===== Begin GnuPG log =====
. gpg: keyring `/root/.gnupg/secring.gpg' created
. gpg: keyring `/root/.gnupg/pubring.gpg' created
. gpg: encrypted with ELG-E key, ID F0B37321
. gpg: decryption failed: secret key not available
. ===== End GnuPG log ===== irgendwie versucht duply die Metadaten von remote zu bekommen und bricht dann ab.
|
unbuntuS12
Anmeldungsdatum: 2. Juni 2010
Beiträge: 1816
|
Hallo Andreas, bitte zeig mal gpg -K Ich habe die Vermutung, dass der verwendete Schlüssel ein Unterschlüssel ist. Ich kann mich erinnern, dass es in Duplicity irgendwann mal eine Umstellung gab, die mich auch in meinem Skript dazu gezwungen hat, explizit den Verschlüsselungsunterschlüssel bzw. den Signaturunterschlüssel des zugehörigen Hauptschlüssels anzugeben. Ich weiß noch nicht ob das bei dir in eine ähnliche Richtung gehen kann, aber vielleicht sind wir mit der Ausgabe schlauer.
|
AndreasMu
(Themenstarter)
Anmeldungsdatum: 8. August 2014
Beiträge: 30
|
Die Ausgabe ist
root@vmd7708:/etc/duply/s3complete_V2# gpg -K
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
Lt. Beschreibung im Wiki sollte da jetzt eigentlich meine Keys angezeigt werden... also passt da doch was nicht.
Die Frage ist halt nur, was sich seit 5 Tagen verändert hat, davor lief doch alles.
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3390
|
Hallo Andreas, zwige bitte auch einmal den Inhalt von /etc/duply/s3complete: ls -la /etc/duply/s3complete das scheint mir ein Ordner zu sein, wo Backups der benötigten Schlüssel liegen. AndreasMu schrieb: Ich habe hier mal die Ausgabe eines Versuchs für ein neues Fullbackup: Import keyfile '/etc/duply/s3complete/gpgkey.5BE9CED8.pub.asc' to keyring (OK)
Import keyfile '/etc/duply/s3complete/gpgkey.5BE9CED8.sec.asc' to keyring (OK)
Immerhin importiert duply hier einen neuen Schlüssel aus diesem Ordner in den Schlüsselring. Vielleicht ist der alte ja auch noch da (sodass wir den selber importieren könnten). Zu der Sache mit den Metadaten: Da war eine falsche Dateiendung! AndreasMu schrieb: NOTICE 1
. Synchronizing remote metadata to local cache...
NOTICE 1
. Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-full-signatures.20150403T074544Z.sigtar.mp4 (not authoritative at backend).
[...]
NOTICE 1
. Copying duplicity-full-signatures.20150403T074544Z.sigtar.gpg to local cache.
Hast du eine Idee, wo die herkommen könnte? Duplicity hat daraufhin, die fehlerhaft benannten lokalen Kopien weggeschmissen und durch die Remotdaten ersetzt. Prüfe doch mal, ob es dabei zu einem Kopierfehler kam:
duplicity collection-status file:///media/hier/deinen/Pfad/zum/Backup/eintragen Viele Grüße Vej
|
AndreasMu
(Themenstarter)
Anmeldungsdatum: 8. August 2014
Beiträge: 30
|
So, jetzt habe ich mal die beiden Schlüssel importiert und bekomme folgendes beim Befehl
root@vmd7708:/# gpg -K
/root/.gnupg/secring.gpg
------------------------
sec 2048D/5BE9CED8 2014-08-08
uid Andreas Murr (backup) <andreas.murr.lohr@t-online.de>
ssb 2048g/F0B37321 2014-08-08
Wenn ich jetzt aber das duply wieder anstarte bekomme ich das hier
Start duply v1.8.0, time is 2015-08-30 12:07:48.
Using profile '/etc/duply/s3complete'.
Using installed duplicity version 0.6.23, python 2.7.8, gpg 1.4.16 (Home: ~/.gnupg), awk 'mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan', bash '4.3.30(1)-release (x86_64-pc-linux-gnu)'.
Encryption public key '5BE9CED8' not found.
Import keyfile '/etc/duply/s3complete/gpgkey.5BE9CED8.pub.asc' to keyring (OK)
Import keyfile '/etc/duply/s3complete/gpgkey.5BE9CED8.sec.asc' to keyring (OK)
Autoset trust of key '5BE9CED8'to ultimate (OK)
Autoset found secret key of first GPG_KEY entry '5BE9CED8' for signing.
Test - Encrypt to 5BE9CED8 & Sign with 5BE9CED8 (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.28324.1440929268_*'(OK)
--- Start running command PRE at 12:07:48.820 ---
Running '/etc/duply/s3complete/pre' - OK
--- Finished state OK at 12:07:48.842 - Runtime 00:00:00.022 ---
--- Start running command BKP at 12:07:48.856 ---
Reading globbing filelist /etc/duply/s3complete/exclude
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20150403T074544Z.sigtar.gpg to local cache.
Copying duplicity-full-signatures.20150503T150004Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: encrypted with ELG-E key, ID F0B37321
gpg: decryption failed: secret key not available
===== End GnuPG log =====
12:08:28.207 Task 'BKP' failed with exit code '31'.
--- Finished state FAILED 'code 31' at 12:08:28.207 - Runtime 00:00:39.350 ---
--- Start running command POST at 12:08:28.231 ---
Running '/etc/duply/s3complete/post' - OK
Output: Aug 30 12:08:28 vmd7708 sendEmail[28711]: Email was sent successfully!
--- Finished state OK at 12:08:28.735 - Runtime 00:00:00.503 ---
--- Start running command PURGEFULL at 12:08:28.752 ---
Synchronizing remote metadata to local cache...
Deleting local /root/.cache/duplicity/duply_s3complete/duplicity-full-signatures.20150403T074544Z.sigtar.mp4 (not authoritative at backend).
Copying duplicity-full-signatures.20150403T074544Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with ELG-E key, ID F0B37321
gpg: decryption failed: secret key not available
===== End GnuPG log =====
12:08:36.022 Task 'PURGEFULL' failed with exit code '31'.
--- Finished state FAILED 'code 31' at 12:08:36.022 - Runtime 00:00:07.270 ---
und danach sind die Schlüssel wieder unbekannt?
root@vmd7708:/# gpg -K
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
root@vmd7708:/#
|
Vej
Moderator, Supporter
Anmeldungsdatum: 7. März 2013
Beiträge: 3390
|
Hallo nochmal. AndreasMu schrieb: Die Ausgabe ist
root@vmd7708:/etc/duply/s3complete_V2# gpg -K
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
Lt. Beschreibung im Wiki sollte da jetzt eigentlich meine Keys angezeigt werden... also passt da doch was nicht.
Die Frage ist halt nur, was sich seit 5 Tagen verändert hat, davor lief doch alles.
Ich vermute, dass hier nicht der Standardschlüsselbund zum Einsatz kommt. Ist zumindest bei anderen Frontends für duplicity (z.B. Déjà Dup) auch so.
EDIT: Der überschneidende Post von dir hat diese Vermutung wohl widerlegt. Die Sicherung wird und wurde aber unter dem Benutzer root durchgeführt?
Vej
|
AndreasMu
(Themenstarter)
Anmeldungsdatum: 8. August 2014
Beiträge: 30
|
aaaahhh.... das mit dem .mp4 kommt aus einem Skript, wo ich in einem Verzeichnis, wo MOV Videodaten liegen, alles in ein mp4 Format umwandeln will.
Da habe ich wohl den Fehler gemacht und lese ALLE Daten von "/" aus weg und erstelle .mp4 files.
Hier das Skript:
if [ `ls -1a|wc -l` -gt 2 ]; then
cd /owncloud-data/timo/files/Videos/_input\ unkomprimiert/
for file in $(find ! -name "*.mp4")
do
outfile=${file%.*}".mp4"
ffmpeg -i "$file" -c:v libx264 -vf scale=-2:480 -t 20 -c:a libmp3lame -$
mv $outfile /owncloud-data/timo/files/Videos/_output\ komprimiert/
rm $file
done
fi
|
AndreasMu
(Themenstarter)
Anmeldungsdatum: 8. August 2014
Beiträge: 30
|
Ich habe jetzt mal versucht, die keys neu zu importieren. Nach dem Start von duply kommt jetzt das:
Test - Encrypt to 5BE9CED8 & Sign with 5BE9CED8 (FAILED)
Sorry. A fatal ERROR occured:
Encryption failed (Code 2).
[GNUPG:] USERID_HINT 7F74A0FE5BE9CED8 Andreas Murr (backup) <andreas.murr.lohr@t-online.de>
[GNUPG:] NEED_PASSPHRASE 7F74A0FE5BE9CED8 7F74A0FE5BE9CED8 17 0
[GNUPG:] GOOD_PASSPHRASE
gpg: F0B37321: There is no assurance this key belongs to the named user
[GNUPG:] INV_RECP 10 5BE9CED8
gpg: /usr/bin/duply: sign+encrypt failed: unusable public key
Hints:
Key '5BE9CED8' seems to be untrusted. If you really trust this key try to
'gpg --edit-key 5BE9CED8' and raise the trust level to ultimate. If you
can trust all of your keys set GPG_OPTS='--trust-model always' in conf file.
This error means that gpg is probably misconfigured or not working
correctly. The error message above should help to solve the problem.
However, if for some reason duply should misinterpret the situation you
can define GPG_TEST='disabled' in the conf file to bypass the test.
Please do not forget to report the bug in order to resolve the problem
in future versions of duply.
|
AndreasMu
(Themenstarter)
Anmeldungsdatum: 8. August 2014
Beiträge: 30
|
So, ist gelöst... ich habe wie beschrieben den Trustlevel auf "ultimate" gesetzt, jetzt rennt alles wieder.
Das Problem war wohl, dass dieses blöde Skript für die Umwandlung der Videodateien die gecachten backup signaturen zerschossen hat, darauf hin dann das duply die remote Versionen geladen hat. Da aber das Skript in kurzen Zeitabständen über crontab gestartet wird, hat es beim zurücksichern dazwischengefunkt und dann die sig-Datei(en) unbrauchbar gemacht. Danke für eure Geduld und an Vej für die Frage mit dem *.mp4... was für ein Sch* mir da passiert ist.
|