[Duplicity-talk] Re: What exactly duplicity check on Verify step? Why i get 'Difference found: File xxxxx has mtime Wed Jan 19 09:49:14 2011, expected Wed Jan 19 00:21:25 2011'?

[Ali Nebi]

Thanks for reply.

Thanks for the links. i am reading it already.
Yes, it is really confusing. Why it is necessary to compare already backed up data with source just after created backup, as it is always possible some file to be changed!? We were using DAR previously and it test the backup archive at the end and it actually verify archive health, but does not very file in backup with source at the end of the backup. Yes, i agree with you. I think this should be removed as this is confusing users :) And yes, it will be better to be part of a new command 'compared' as you mentioned in your post.

Message: 6
Date: Wed, 19 Jan 2011 11:46:49 +0100
From: address@hidden
Subject: Re: [Duplicity-talk] What exactly duplicity check on Verify
       step?   Why i get 'Difference found: File xxxxx has mtime Wed Jan 19
       09:49:14        2011, expected Wed Jan 19 00:21:25 2011'?
To: Discussion of the backup program duplicity
       <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On 19.01.2011 10:02, Ali Nebi wrote:
>
> 1. What duplicity exactly checks in Verify step?

you might want to read here
https://answers.launchpad.net/duplicity/+question/116587

> 2. Why we get 'Difference found: File etc/resolv.conf has mtime Wed Jan 19 09:49:14 2011, expected Wed Jan 19 00:21:25 2011' lines on this process?

confusing isn't it. For reasons not transparent to me, additionally to verifying the backed up data, verify also compares the date with the source. This should be removed from my point of view. It could be part of a new command compare, which actually really compares backup with source.

> 3. Is this an error in backup process and does this break my backup and it is not ok?

that's design. If verify finds differences it always returns 1 and not 0 (success). If you can explain the difference (e.g. file likely modified during backup) you can ignore it.

> 4. Verify return status 1, does this mean that my backup is broken and i should take care for those listed files or the backup is healthy and fully functional?

as in 3. .. ede/duply.net



------------------------------

Message: 7
Date: Wed, 19 Jan 2011 11:50:06 +0100
From: address@hidden
Subject: Re: [Duplicity-talk] Re: Copied files, all modified now.
To: Discussion of the backup program duplicity
       <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On 19.01.2011 09:50, Jeff Cook wrote:
> Ah, actually, I remember now I did do a recursive permissions change
> across the repository. Is there a way to make rsync introspect to the
> degree that it only alters the chmod instead of attempting to send the
> whole thing back up? This is a large dataset and our host bills for
> bandwidth.

Even if there'd be, it is not implemented in duplicity to do so. So either change the permissions back or live with the fact .. sorry ede/duply.net



------------------------------

_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk


End of Duplicity-talk Digest, Vol 90, Issue 14
**********************************************