Re: [Duplicity-talk] duplicity verification and corrupt backups

[edgar . soldin]

On 17.08.2011 17:06, Rob Verduijn wrote:
> But now I add a slow line and a huge amount of data. There is enough space on 
> the destination side so that is not the problem.
> But after uploading say 250Gb over a slow line for several days
>  it becomes a bit of a pain that after doing a verify it tells me file 312 
> out of 2631 has failed it's check, and stops.
> 
> How do you fix that one corrupt file ?

you don't/can't with duplicity. You can either - assuming your backup chain is 
consistent but only a few files fail to verify - add an incremental or in all 
other cases have to do a new full.

> How can I get it to continue to verify the other files ?

Ok, if it stops verifying than it should throw an error stack or similar, 
telling what the problem is. Usually it is a checksum error. In this case your 
chain is corrupted and you can go back to the next older backup and verify and 
repeat this until you find aa state that works.

> I'm not looking forward to doing a full new backup, one that takes days and 
> one that could also fail.
> Neither am I looking forward to driving over to the remote location fetching 
> the drive, going home, doing a backup driving there again putting it back in 
> the machine.

Good to know. But seriously. A slim line also minimizes the throughput and 
therefor the data you can put through it over a timeframe. Doing a full over a 
timeframe of more than a day is challenging at best. I would not advise it.

Rather

A) split the backup into small parts that are not backed that often
or
B) do what lot's of people with slow upload channels do. Do duplicity backup to 
a local file:// target and rsync or upload it with the software of your 
preference to the remote site.

..ede/duply.net