Re: [Duplicity-talk] Feedback based on restore experience

[edgar . soldin]

On 24.07.2014 09:47, Sergei G wrote:
> Background: My old Mac Mini failed, so I had to restore data from duplicity 
> backup. Unfortunately, I experienced a set of mostly unrelated issues with 
> hardware and FreeBSD 10 handling of external USB drives. These issues made me 
> to try restore multiple times. My experience ended up focused on sftp and 
> later ftp.
> 
> Absolutely every attempt was delayed by a single type of error message:
>     CollectionsError: No backup chains found
> I provide a full stack trace at the end.
> 
> The problem with this error is that it reports a consequence and not an 
> issue. Duplicity failed to get to the desired source directory, but it fails 
> to report the preceding error.
> 
> For example, If FTP user's root is /home/userName, but backup is at 
> /mnt/extufs/, FTP client will fail to cd to the new directory, while 
> interactive console will have no problem.  FTP failure to change path is not 
> properly reported and that's the preceding error.
> 
> From what I remember the absolute form of sftp was one of the reasons for the 
> same error message. I think sftp properly reports failure to cd to the remote 
> directory. In my case, I was using sftp://address@hidden/abs/path/to/dir, but 
> I should've used sftp://address@hidden//abs/path/to/dir. RTFM, but reporting 
> a hint would be nice.
> 
> I usually had to find answers using other programs to questions:
> 
> 1. What's my login remote directory? Is it the same as in other program I 
> used?
> 2. What's my current remote directory when error occurred?
> 
> Answers to both questions from duplicity itself would make my life easier 
> when troubleshooting.
> 
> Another set of problems was connected to incomplete error reporting when 
> calling command line programs. I had a missing gpg command and I could not 
> figure out its name, but its arguments were reported in the error message. I 
> actually had to add print statements to source code to see what's the name of 
> the missing application.
> 
> 
> Here is a full stack trace for the typical FTP error:
> 
> NcFTP version is 3.2.5
> Local and Remote metadata are synchronized, no sync needed.
> Last full backup date: none
> Traceback (most recent call last):
>   File "/Users/sergei/.py-virtualenvs/duplicity/bin/duplicity", line 1502, in 
> <module>
>     with_tempdir(main)
>   File "/Users/sergei/.py-virtualenvs/duplicity/bin/duplicity", line 1496, in 
> with_tempdir
>     fn()
>   File "/Users/sergei/.py-virtualenvs/duplicity/bin/duplicity", line 1345, in 
> main
>     do_backup(action)
>   File "/Users/sergei/.py-virtualenvs/duplicity/bin/duplicity", line 1430, in 
> do_backup
>     restore(col_stats)
>   File "/Users/sergei/.py-virtualenvs/duplicity/bin/duplicity", line 693, in 
> restore
>     restore_get_patched_rop_iter(col_stats)):
>   File "/Users/sergei/.py-virtualenvs/duplicity/bin/duplicity", line 715, in 
> restore_get_patched_rop_iter
>     backup_chain = col_stats.get_backup_chain_at_time(time)
>   File 
> "/Users/sergei/.py-virtualenvs/duplicity/lib/python2.7/site-packages/duplicity/collections.py",
>  line 952, in get_backup_chain_at_time
>     raise CollectionsError("No backup chains found")
> CollectionsError: No backup chains found
> 

true, there are imperfections in duplicity. mainly because contributions are 
sparse and there is no dedicated development going on in the project. we are 
three people who spend some time if possible but are otherwise quite busy.

wrt. your issues - some of them you might have circumvented by using duply. it 
keeps settings (path, keys etc.) in a conf file and checks if needed binaries 
are available e.g. gpg . give it a try and simply save the profile folder 
somewhere save for the next time you need to restore.

..ede/duply.net