Frequent BackendException:s lately (SFTP) (lp:#946992)

[Original report](https://bugs.launchpad.net/bugs/946992) created by **Daniel Andersson (drandersson)**
```
I have had a backup script using duplicity running 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" (I haven't gotten a "-v9"
report since it doesn't always happen)):

"""
AsyncScheduler: task execution done (success: False)
....[some files added 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 are transferred.

Perhaps it is a local connection error that always have existed, but the
previous SFTP backend retried as default action instead of failing.

Also reported as Debian bug #659007, but it has gotten no attention for a
month.

Duplicity 0.6.17
Python 2.7.2+
Debian Sid
Linux
```

Story points: 30.0