|
From: | Steven Willoughby |
Subject: | Re: [rdiff-backup-users] Error "Unable to compare" BUT THEN"Nochanges found. Directory matches." What? |
Date: | Thu, 12 Aug 2010 16:35:48 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 |
On 08/12/2010 03:55 PM, Robinson, Eric wrote:
You mean the rdiff-backup version? It's 1.2.8 on both servers. But does it to an in-place comparison? If I understand the man page correctly, it first copies the data from the dest to the source and then compares it there?
I'm also running 1.2.8 on my hosts, I'm not sure why you are getting warnings with --compare-hash. In any case, I think you misunderstood the man page (if you're talking about what it says for --compare-hash). It will re-read all of the data on the source side in order to compute a hash and then compare that hash with what is stored in the backup metadata. I haven't seen the code in question or ever used this option before yesterday so I'm not 100% sure that the data won't be transferred over the network, but it shouldn't be.
I definitely care about more than just the most recent backup. I need to be able to restore from prevous days, weeks, and months, which was the whole point of using rdiff-backup in the first place. But I can understand using the most recent backup as a benchmark for testing the backup quality.
If you're testing backup quality then you should use the --verify-at-time option instead of the --compare option. I have been using it in production (debian stable, rdiff-backup 1.2.5) for a long time. I think the intention of the --compare option is to see what files have changed on the source, not to verify old backups.
Steven
[Prev in Thread] | Current Thread | [Next in Thread] |