Re: [Duplicity-talk] Strange problem using duplicity

[Kenneth Loafman]

Peter Schuller wrote:
>> calzone:~# sh duplicity.sh
>> Warning, found incomplete backup sets, probably left from aborted session
>> No signatures found, switching to full backup.
>> Error initializing file /dev/log
>> Traceback (most recent call last):
>>   File "/usr/bin/duplicity", line 373, in ?
>>     if __name__ == "__main__": main()
>>   File "/usr/bin/duplicity", line 366, in main
>>     if not sig_chain: full_backup(col_stats)
>>   File "/usr/bin/duplicity", line 142, in full_backup
>>     bytes_written = write_multivol("full", tarblock_iter, globals.backend)
>>   File "/usr/bin/duplicity", line 89, in write_multivol
>>     backend.put(tdp, dest_filename)
>>   File "/usr/lib/python2.4/site-packages/duplicity/backends.py", line
>> 349, in put
>>     self.error_wrap('storbinary', "STOR "+remote_filename, source_file)
>>   File "/usr/lib/python2.4/site-packages/duplicity/backends.py", line
>> 335, in error_wrap
>>     except ftplib.all_errors, e: raise BackendException(e)
>> duplicity.backends.BackendException: 421 Idle timeout (180 seconds):
>> closing control connection
> 
> Although I share the reluctance to backup the entire / without
> exceptions, the above happening as a result of this is a bug IMO. The
> backend should not rely on established connections to an FTP server
> surviving for unreasonable amounts of time.
> 
> I had a quck look at the ftp backend and it does look like it is doing
> this. I'll file a bug for it, and while I may look at submitting a
> patch I'm not making promises.

The ftp backend uses ncftpls,get,put to do its work.  Its strictly one
file per invocation, so if its timing out at 180 seconds, then the
network or remote has indeed gone unresponsive for that long.

The traceback above looks like an older version of duplicity.  There's
no ftplib in duplicity any longer.  An update to the newest version may
help get rid of some of the problems.

...Ken

signature.asc
Description: OpenPGP digital signature