← Back to team overview

duplicity-team team mailing list archive

Re: [Question #248111]: Duplicity Adds the same file again after full backup

 

Question #248111 on Duplicity changed:
https://answers.launchpad.net/duplicity/+question/248111

    Status: Open => Answered

edso proposed the following answer:
On 03.05.2014 20:56, Rodrigo Alvarez wrote:
> New question #248111 on Duplicity:
> https://answers.launchpad.net/duplicity/+question/248111
> 
> I run a backup on my photo library and since it is the first time duplicity does a full backup.  It successfully finishes by adding all the files and creating the duplicity-full* volumes and duplicity-full-signatures.* files. 
> 
> Next day I run the backup again, and now duplicity start an incremental backup.   However, this time around, it also adds a lot of files again. These files were already added in the first full backup and have not changed since 2010.   
> 
> On the third day, I run my backup again and now duplicity is does not add all this files (as it should).  
> 
> I'm running a rather large set so the double store is a good-sized nuisance.   Any suggestions?  How is duplicity determining that the files change/or don't? 

duplicity checks modification time, size, permissions, owner .. if there
is a difference the files are backed up again. backing up means running
it against librsync, comparing blocks (rolling checksum) and only saving
changed blocks and changed metadata.

so, if your files really didn't change but are added again it shouldn't
hurt as no data changed.

anyway run duplicity with max. verbosity '-v9' and it will tell you, a
bit cryptic but understandable, why it thinks the file should be backed
up agn.

> 
> This is running on Ubuntu 12.04 and duplicity 0.6.18 (February 29, 2012) with Python 2.7.3. 

update to the latest stable.. lots of changes since 2 years

what is your source's file system?


..ede/duply.net

-- 
You received this question notification because you are a member of
duplicity-team, which is an answer contact for Duplicity.