[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Backup not identifying changed file, even thoug

From: Dominic Raferd
Subject: Re: [rdiff-backup-users] Backup not identifying changed file, even though hash is different
Date: Thu, 24 Mar 2011 13:02:55 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20110303 Thunderbird/3.1.9

On 24/03/2011 00:07, Patrick Nagel wrote:
Hash: SHA1


On 2011-03-24 06:29, Scott Jilek wrote:
Is there any way to force Rdiff to use a hash compare for difference
triggering?  I looked over the manual, and nothing seems to be what I'm
looking for.
I've tried adding the "--compare-hash" switch.  The MAN page isn't specific
about the function of --compare-hash, however it appears to be only for
VERIFICATION and not for candidate IDENTIFICATION, as causes rdiff to simply
show a report telling me this file is not in sync. When I use that switch no
backups occur from what I can tell as no increments are created.

Is there some way to explicitly force Rdiff to create a backup of specific
files?  What am I missing, because this seems like a huge gap in
functionality if it's only using file timestamps.
I guess it would be nice to have an option to make rdiff-backup identify
changed files by checksum/hash. That being said, I think I wouldn't want to
use it for anything, because it would be extremely slow. It would need to
read all files from start to end, while hashing them, at each backup run.
For a large backup repository with, say, 500 GB worth of files, the backup
would take more than an hour, even if not a single file changed (assuming
100 MB/s read and hashing speed).

By the way, rsync also wouldn't consider that truecrypt container as
"changed", by default - you would need to add the '-c' option. And maybe
that's the best way to handle this: Exclude the truecrypt container(s) from
your rdiff-backup, and instead use rsync -c for that.
Alternatively you could 'touch' the truecrypt container just before the
backup, so that the modification timestamp gets changed, and rdiff-backup
will pick it up (but then it would create a diff every time, which would
take even longer than the 'rsync -c' method - but maybe you really want the
history of that file...).


I would echo the suggestion to touch the file. You can download a free touch.exe program from the net. I use it with -m option in a similar case to force rdiff-backup (via TimeDicer) to pick up a vmdk file.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]