-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alexander Zangerl schrieb:
> first: i cannot reproduce your problem.
>
For me the problem persists.
> please retry, and nuke ~/.cache before you do retry your tests. please
> also rerun with -v 9 and submit that log for further debugging.
$ rm -r ~/.cache/duplicity
$ duplicity --encrypt-key XXXXXXXX test file://testbackup
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
No signatures found, switching to full backup.
...
Errors 0
- -------------------------------------------------
$ touch test/testfile
$ duplicity --encrypt-key XXXXXXXX test file://testbackup -v 9
Using archive dir:
/home/konrad/.cache/duplicity/e382dc88866c505d65b71a6a8b959101
Using backup name: e382dc88866c505d65b71a6a8b959101
Import of duplicity.backends.ftpbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.sshbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.cloudfilesbackend Succeeded
Import of duplicity.backends.botobackend Succeeded
Main action: inc
================================================================================
duplicity 0.6.06 (October 29, 2009)
Args: /usr/bin/duplicity --encrypt-key 17631C0B test file://testbackup
- -v 9
Linux berlin 2.6.32.2 #1 PREEMPT Tue Dec 8 21:37:04 CET 2009 i686
/usr/bin/python 2.5.4 (r254:67916, Nov 19 2009, 19:46:21)
[GCC 4.3.4]
================================================================================
Using temporary directory /tmp/duplicity-4HXB_f-tempdir
Registering (mkstemp) temporary file
/tmp/duplicity-4HXB_f-tempdir/mkstemp-eOQRQm-1
Temp has 9189302272 available, backup will use approx 34078720.
Local and Remote metadata are synchronized, no sync needed.
3 files exist on backend
2 files exist in cache
Extracting backup chains from list of files:
['duplicity-full-signatures.20100120T205359Z.sigtar.gpg',
'duplicity-full.20100120T205359Z.manifest.gpg',
'duplicity-full.20100120T205359Z.vol1.difftar.gpg']
File duplicity-full-signatures.20100120T205359Z.sigtar.gpg is not part
of a known set; creating new set
Ignoring file (rejected by backup set)
'duplicity-full-signatures.20100120T205359Z.sigtar.gpg'
File duplicity-full.20100120T205359Z.manifest.gpg is not part of a known
set; creating new set
File duplicity-full.20100120T205359Z.vol1.difftar.gpg is part of known
set
Found backup chain [Wed Jan 20 21:53:59 2010]-[Wed Jan 20 21:53:59 2010]
Last full backup date: Wed Jan 20 21:53:59 2010
Collection Status
- -----------------
Connecting with backend: LocalBackend
Archive dir:
/home/konrad/.cache/duplicity/e382dc88866c505d65b71a6a8b959101
Found 0 secondary backup chains.
Found primary backup chain with matching signature chain:
- -------------------------
Chain start time: Wed Jan 20 21:53:59 2010
Chain end time: Wed Jan 20 21:53:59 2010
Number of contained backup sets: 1
Total number of contained volumes: 1
Type of backup set: Time: Num volumes:
Full Wed Jan 20 21:53:59 2010 1
- -------------------------
No orphaned or incomplete backup sets found.
Registering (mktemp) temporary file
/tmp/duplicity-4HXB_f-tempdir/mktemp-W8wpyS-2
Removing still remembered temporary file
/tmp/duplicity-4HXB_f-tempdir/mktemp-W8wpyS-2
Removing still remembered temporary file
/tmp/duplicity-4HXB_f-tempdir/mkstemp-eOQRQm-1
GPG error detail: Traceback (most recent call last):
File "/usr/bin/duplicity", line 1236, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1229, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1210, in main
check_last_manifest(col_stats) # not needed for full backup
File "/usr/bin/duplicity", line 970, in check_last_manifest
last_backup_set.check_manifests()
File "/usr/lib/python2.5/site-packages/duplicity/collections.py", line
180, in check_manifests
remote_manifest = self.get_remote_manifest()
File "/usr/lib/python2.5/site-packages/duplicity/collections.py", line
214, in get_remote_manifest
manifest_buffer = self.backend.get_data(self.remote_manifest_name)
File "/usr/lib/python2.5/site-packages/duplicity/backend.py", line
490, in get_data
assert not fin.close()
File "/usr/lib/python2.5/site-packages/duplicity/dup_temp.py", line
210, in close
assert not self.fileobj.close()
File "/usr/lib/python2.5/site-packages/duplicity/gpg.py", line 201, in
close
self.gpg_failed()
File "/usr/lib/python2.5/site-packages/duplicity/gpg.py", line 168, in
gpg_failed
raise GPGError, msg
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: verschlüsselt mit 4096-Bit ELG-E Schlüssel, ID XXXXXXXX, erzeugt
2007-08-17
"Konrad Zimmermann (E-Mail) <XXXXXXXXXX>"
gpg: Entschlüsselung mit Public-Key-Verfahren fehlgeschlagen: Falsche
Passphrase
gpg: Entschlüsselung fehlgeschlagen: Geheimer Schlüssel ist nicht vorhanden
===== End GnuPG log =====
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: verschlüsselt mit 4096-Bit ELG-E Schlüssel, ID XXXXXXXX, erzeugt
2007-08-17
"Konrad Zimmermann (E-Mail) <XXXXXXXXXX>"
gpg: Entschlüsselung mit Public-Key-Verfahren fehlgeschlagen: Falsche
Passphrase
gpg: Entschlüsselung fehlgeschlagen: Geheimer Schlüssel ist nicht vorhanden
===== End GnuPG log =====
> ...and i know of exactly one scenario that can cause duplicity
> to need decryption:
>
> duplicity since 0.6 absolutely requires an unencrypted local cache of
> filenames/signatures (the archivedir stuff).
> this is forcibly generated (in ~/.cache or controlled by --archive-dir/--name)
> on new backups, and kept up to date subsequently.
>
> and here's the rub: for some as of yet unresolved reason (see
> https://bugs.launchpad.net/duplicity/+bug/497243 for my report on
> this issue) i've seen 0.6.06 occasionally and on long incremental chains
> end up with desynchronized local cache vs. remote archive, with the remote
> archive having more (encrypted) stuff than the cache accounts for.
> it detects this, and attemps a resynchronization: copies over signatures
> from the remote archive and attempts to decrypt them - and fails.
>
> (this buggy behaviour is NOT present in 0.6.05.)
May be the same problem (only without the long backup chains) since I am
running 0.6.06.
Any more useful info I might provide?
Regards
Konrad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAktXcboACgkQnpKH9hdjHAsffACcDFyCO7ol2ErdRCAiwiUc3kKg
VVoAoI2EdKJ9Ku9EGRZrystoZlu4J9Ek
=LvM7
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
