Re: [Duplicity-talk] Losing incremental backups

[Kenneth Loafman]

Greg,

I think you are correct in your analysis.  I will check it out and get
it fixed if that's the case.  Thanks for the heads up!

...Ken

Greg Hartman wrote:
> I have been using duplicity for about six months.
> Recently I have encountered a problem where my backups
> suddenly fail. I am able to reproduce this bug on the
> 0.4.3 release. I have pasted the error messages
> returned by duplicity below.
> 
> I did some investigation, and it looks to me like the
> problem is related to an assumption that listdir()
> will return pathnames in the same order that the files
> were originally written to disk. This seems to be the
> assumption in set_values in collections.py, but I'm
> not very familiar with the Ruby and the code, so I may
> be wrong.
> 
> Some UNIX filesystems, including ext3 with the
> dir_index option set, use specialized data structures
> to speed up path name resolution. This often means
> that the order of existing files can change when files
> are added to directories. I'm fairly convinced that
> this is what happened to my backups.
> 
>>From what I can tell the sigtar files may come before
> the difftar files in the list. The error messages seem
> to indicate that duplicity ignores the sigtars when
> this happens and then complains that the difftar files
> are orphaned.
> 
> This seems to cause problems with the backups, which
> isn't surprising since duplicity probably believes
> that the chain of incremental backups is broken.
> 
> Is my analysis of the failure correct? If so, what is
> the right solution? I'm assuming that this problem
> could affect all of the backends, so perhaps some
> sorting or a more robust matching algorithm in
> set_values in collections.py would be in order.

signature.asc
Description: OpenPGP digital signature