Your message dated Sun, 19 Feb 2012 14:43:37 +0100
with message-id <[email protected]>
and subject line Re: Bug#659008: duplicity: Restart fails with
BackendException: sftp put ... failed: Failure
has caused the Debian Bug report #659008,
regarding duplicity: Restart fails with BackendException: sftp put ... failed:
Failure
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
659008: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659008
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: duplicity
Version: 0.6.17-1
Severity: normal
Hi.
Here's what happens :
# LANG=C duplicity full --no-print-statistics --scp-command 'scp '
--sftp-command 'sftp ' --extra-clean --archive-dir
/var/cache/backupninja/duplicity --exclude '/home/*/.local/share/Trash'
--exclude '/home/*/.Trash' --include '/home' --exclude '**' /
scp://backup@whetever//mnt/backups/whatever
Warning: Option --scp-command is deprecated and ignored. Use --ssh-options
instead.
Warning: Option --sftp-command is deprecated and ignored. Use --ssh-options
instead.
Local and Remote metadata are synchronized, no sync needed.
Last full backup left a partial set, restarting.
Last full backup date: Tue Feb 7 01:36:09 2012
GnuPG passphrase:
Retype passphrase to confirm:
RESTART: Volumes 291 to 291 failed to upload before termination.
Restarting backup at volume 291.
Restarting after volume 290, file /.../whatever, block 2669
BackendException: sftp put of /tmp/duplicity-kAlv2U-tempdir/mktemp-jaj5JJ-3 (as
duplicity-full.20120207T003609Z.vol291.difftar.gpg) failed: Failure
The message is rather cryptic :-(
Thanks in advance.
Best regards,
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (650, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.1.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages duplicity depends on:
ii libc6 2.13-24
ii librsync1 0.9.7-8
ii python 2.7.2-10
ii python-gnupginterface 0.3.2-9.1
ii python2.7 2.7.2-8
Versions of packages duplicity recommends:
ii python-paramiko 1.7.7.1-2
ii rsync 3.0.9-1
Versions of packages duplicity suggests:
pn lftp 4.3.4-1
pn ncftp 2:3.2.5-1
pn python-boto <none>
pn python-cloudfiles <none>
pn python-gdata 2.0.14-2
pn python-pexpect 2.3-1
pn tahoe-lafs <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Alexander Zangerl <[email protected]> writes:
> before 0.6.17-4 paramiko's debug output wasn't enabled/integrated in
> duplicity; could you
> please retry with -v9 with 0.6.17-4 (which will be uploaded to unstable
> today)?
>
I have had better results, i.e., no more failures with the -4
version... but maybe that's not really caused by the changes, just
because the failure condition isn't there anymore.
> could you also check if the offending file already exists on the target when
> the
> sftp put fails?
>
Trying on another machine with same version, however, I've experienced
problems, but when I checked, I discovered that the file was indeed
there... and that the destination partition was indeed full ! ;-)
Guess what... I'm feeling stupid.
Anyway, I hope that the new logging mechanism will help.
Sorry about the bothering.
Best regards,
--
Olivier BERGER
(OpenPGP: 4096R/7C5BB6A5)
http://www.olivierberger.com/weblog/
--- End Message ---
