duplicity-team team mailing list archive

[edgar.soldin@xxxxxx]

On 16.11.2013 14:36, Michael Terry wrote:
> On 16 November 2013 06:12, <edgar.soldin@xxxxxx <mailto:edgar.soldin@xxxxxx>> wrote:
> 
>     don't see any reason to scan the whole backup. why would you do that?
> 
> 
> Well, if our philosophy is "when restarting, notice deletions in sources", theoretically we would want to make sure all of the files in our partial backup are still there.  Though that theory might also extend to the data itself and we start doing a lot of work.  I'm not advocating for that.
> 

no backup software can guarantee a consistent snapshot in time if the source location changes during the backup. so, yes, let's not do that. if users want that they should backup (read only) snapshots.  
  
> 
>     aim should be to get rid of incompletely backed up source files if their state changed in between (modified, deleted) as resuming them can result i a corrupt backed up file.
> 
> 
> Well, it's not like we're going to corrupt a file you care about.  You deleted it after all.  You probably won't mind if duplicity is holding on to half of it for you.

solid arguing except that the real problem arises on restore where the user expects a proper backed up file and not half of it ;).. what if this is the first full? maybe the file was deleted erroneously. 

of course it would be totally valid to remove the incomplete chunk as a solution or mark as deleted, as the backup should reflect the fs during backup runtime. most important is i guess that we do not backup files into a state that they never were in!

..ede