On Wed, Dec 08, 2010 at 12:47:29PM +1000, Alexander Zangerl wrote:
> On Tue, 07 Dec 2010 09:25:03 +0100, Olivier Berger writes:
> i can't reproduce the problem here; would you please send me the output
> of a run with -v 9 and with (re-)cleaned cache?
>
Here's at least the run with -v 5 :
# duplicity -v 5 --force --ssh-askpass
scp://r...@xxxxx//mnt/IOMEGA_HDD/dupbackups/xxxxx /home/xxxxx/restore/
Using archive dir: /root/.cache/duplicity/a00bfabc635c2934093d231fbc26dadf
Using backup name: a00bfabc635c2934093d231fbc26dadf
Import of duplicity.backends.ftpbackend Succeeded
Import of duplicity.backends.webdavbackend Succeeded
Import of duplicity.backends.localbackend Succeeded
Import of duplicity.backends.imapbackend Succeeded
Import of duplicity.backends.tahoebackend Succeeded
Import of duplicity.backends.rsyncbackend Succeeded
Import of duplicity.backends.sshbackend Succeeded
Import of duplicity.backends.hsibackend Succeeded
Import of duplicity.backends.giobackend Succeeded
Import of duplicity.backends.cloudfilesbackend Succeeded
Import of duplicity.backends.botobackend Succeeded
Password for 'xxxxx':
Main action: restore
PASSPHRASE variable not set, asking user.
GnuPG passphrase:
================================================================================
duplicity 0.6.08b (March 11, 2010)
Args: /usr/bin/duplicity -v 5 --force --ssh-askpass
scp://r...@xxxxx//mnt/IOMEGA_HDD/dupbackups/xxxxx /home/xxxxx/restore/
Linux xxxxx 2.6.32-5-686 #1 SMP Thu Nov 25 18:43:34 UTC 2010 i686
/usr/bin/python 2.6.6 (r266:84292, Oct 9 2010, 11:40:09)
[GCC 4.4.5]
================================================================================
Using temporary directory /tmp/duplicity-p9jsSL-tempdir
Temp has 2661462016 available, backup will use approx 34078720.
Running 'sftp -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@xxxxx'
(attempt #1)
sftp command: 'mkdir "/mnt/IOMEGA_HDD/dupbackups/xxxxx"'
sftp command: 'cd "/mnt/IOMEGA_HDD/dupbackups/xxxxx"'
sftp command: 'ls -1'
Synchronizing remote metadata to local cache...
PASSPHRASE variable not set, asking user.
Copying duplicity-full-signatures.20101206T005609Z.sigtar to local cache.
Running 'sftp -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@xxxxx'
(attempt #1)
sftp command: 'get
"/mnt/IOMEGA_HDD/dupbackups/xxxxx/duplicity-full-signatures.20101206T005609Z.sigtar.gpg"
"/tmp/duplicity-p9jsSL-tempdir/mktemp-uA0Siq-2"'
Deleting /tmp/duplicity-p9jsSL-tempdir/mktemp-uA0Siq-2
Copying duplicity-full.20100116T134814Z.manifest to local cache.
Running 'sftp -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@xxxxx'
(attempt #1)
sftp command: 'get
"/mnt/IOMEGA_HDD/dupbackups/xxxxx/duplicity-full.20100116T134814Z.manifest.gpg"
"/tmp/duplicity-p9jsSL-tempdir/mktemp-p0Ukqx-3"'
Deleting /tmp/duplicity-p9jsSL-tempdir/mktemp-p0Ukqx-3
Copying duplicity-full.20100905T190548Z.manifest to local cache.
Running 'sftp -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@xxxxx'
(attempt #1)
sftp command: 'get
"/mnt/IOMEGA_HDD/dupbackups/xxxxx/duplicity-full.20100905T190548Z.manifest.gpg"
"/tmp/duplicity-p9jsSL-tempdir/mktemp-hu2f4W-4"'
Deleting /tmp/duplicity-p9jsSL-tempdir/mktemp-hu2f4W-4
Copying duplicity-full.20101006T231429Z.manifest to local cache.
Running 'sftp -oServerAliveInterval=15 -oServerAliveCountMax=1 r...@xxxxx'
(attempt #1)
sftp command: 'get
"/mnt/IOMEGA_HDD/dupbackups/xxxxx/duplicity-full.20101006T231429Z.manifest.gpg"
"/tmp/duplicity-p9jsSL-tempdir/mktemp-WiIWB8-5"'
GPG error detail: Traceback (most recent call last):
File "/usr/bin/duplicity", line 1251, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1244, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1145, in main
sync_archive()
File "/usr/bin/duplicity", line 959, in sync_archive
copy_to_local(fn)
File "/usr/bin/duplicity", line 915, in copy_to_local
globals.archive_dir.append(loc_name).name)
File "/usr/bin/duplicity", line 841, in copy_raw
data = src_iter.next(block_size).data
File "/usr/bin/duplicity", line 900, in next
self.fileobj.close()
File "/usr/lib/python2.6/dist-packages/duplicity/dup_temp.py", line 210, in
close
assert not self.fileobj.close()
File "/usr/lib/python2.6/dist-packages/duplicity/gpg.py", line 198, in close
self.gpg_failed()
File "/usr/lib/python2.6/dist-packages/duplicity/gpg.py", line 165, in
gpg_failed
raise GPGError, msg
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: decrypt_message failed: eof
===== End GnuPG log =====
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: decrypt_message failed: eof
===== End GnuPG log =====
> from the lack of log info about backup chains it seems to me that one
> of the manifests is damaged/empty/undecryptable, can you check their file
> sizes
> on the remote storage backend? (ideally run a collection-status and
> list-current-files, too.)
You're right : the duplicity-full.20101006T231429Z.manifest.gpg
file is empty, as well as parts of the corresponding volumes files :-(
I guess that's the cause, indeed, but that should propabably make duplicity
overcome, since, in that case, that's not the latest full backup that needs to
be restored (hopefully).
Thanks for your help.
Should I file a bug upstream, then ?
Best regards,
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
