Package: duplicity
Version: 0.6.17-3
Severity: important
I have had a very simple backup script using duplicity runnig for a long time.
Recently (I have noticed it since mid-January, perhaps related to the
introduction of python-paramiko) it frequently (not always) fails with (using
switches "--asynchronous-upload -v5"):
"""
AsyncScheduler: task execution done (success: False)
....[some files aded to next volume]...
AsyncScheduler: scheduling task for asynchronous execution
AsyncScheduler: a previously scheduled task has failed; propagating the result
immediately
Backend error detail: Traceback (most recent call last):
File "/usr/bin/duplicity", line 1388, in <module>
with_tempdir(main)
File "/usr/bin/duplicity", line 1381, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1351, in main
full_backup(col_stats)
File "/usr/bin/duplicity", line 500, in full_backup
globals.backend)
File "/usr/bin/duplicity", line 399, in write_multivol
(tdp, dest_filename, vol_num)))
File "/usr/lib/python2.7/dist-packages/duplicity/asyncscheduler.py", line
151, in schedule_task
return self.__run_asynchronously(fn, params)
File "/usr/lib/python2.7/dist-packages/duplicity/asyncscheduler.py", line
215, in __run_asynchronously
with_lock(self.__cv, wait_for_and_register_launch)
File "/usr/lib/python2.7/dist-packages/duplicity/dup_threading.py", line 100,
in with_lock
return fn()
File "/usr/lib/python2.7/dist-packages/duplicity/asyncscheduler.py", line
196, in wait_for_and_register_launch
check_pending_failure() # raise on fail
File "/usr/lib/python2.7/dist-packages/duplicity/asyncscheduler.py", line
191, in check_pending_failure
self.__failed_waiter()
File "/usr/lib/python2.7/dist-packages/duplicity/dup_threading.py", line 201,
in caller
value = fn()
File "/usr/lib/python2.7/dist-packages/duplicity/asyncscheduler.py", line
183, in <lambda>
(waiter, caller) = async_split(lambda: fn(*params))
File "/usr/bin/duplicity", line 398, in <lambda>
async_waiters.append(io_scheduler.schedule_task(lambda tdp, dest_filename,
vol_num: put(tdp, dest_filename, vol_num),
File "/usr/bin/duplicity", line 296, in put
backend.put(tdp, dest_filename)
File "/usr/lib/python2.7/dist-packages/duplicity/backends/sshbackend.py",
line 189, in put
raise BackendException("sftp put of %s (as %s) failed: %s" %
(source_path.name,remote_filename,e))
BackendException: sftp put of /media/5-2000/tmp/duplicity-tmp/duplicity-CyAVNR-
tempdir/mktemp-d28oCp-409 (as duplicity-
full.20120207T111003Z.vol408.difftar.gpg) failed: Server connection dropped:
"""
and to STDERR it is written
"""
No handlers could be found for logger "paramiko.transport"
BackendException: sftp put of /media/5-2000/tmp/duplicity-tmp/duplicity-CyAVNR-
tempdir/mktemp-d28oCp-409 (as duplicity-
full.20120207T111003Z.vol408.difftar.gpg) failed: Server connection dropped:
"""
It sounds like a local connection error, but it has never happened before and
the error mentions paramiko explicitly. I have recently started using
"--asynchronous-upload", but I believe it happened before that as well (it is
hard to track down since it seems to happen randomly).
It happens more often during full backups, when 20GB+ is transferred (default
volume size 25MB), than during incremental backups when only a few volumes
typically is transferred.
Perhaps it is a local connection error that always have existed, but the
previous SFTP backend retried as default action instead of failing.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages duplicity depends on:
ii libc6 2.13-26
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-13
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 <none>
pn python-pexpect 2.3-1
pn tahoe-lafs <none>
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
