[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: Scott Jilek
Subject: Re: [rdiff-backup-users] Backup not identifying changed file, even though hash is different
Date: Thu, 24 Mar 2011 12:31:38 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

Unfortunately, I can't just touch the file because it's in use and locked by the truecrypt process.

Is there any plan to add the rsync -c option to rdiff-backup to force "always checksum" for files like this. Obviously it wouldn't be used in most cases, but for known special files like this where timestamps aren't used, it really is the only option.

I could try to install one of the windows rsync variants in this case, but the whole idea of a practical backup process to me is getting multiple snapshots in time, whereas rsync only gives me efficient mirroring. I'm not too keen on mirroring as a backup strategy, because corrupted files completely destroy the usefulness of mirroring. If it's bad in the source, it becomes bad in the singular backup as soon as the backup process runs and then you have no recovery option. With Rdiff, I can go back in time to just before the corruption occurred and restore the file to the last know working time. As far as I'm concerned, simple mirroring is not a safe method of backup


On 3/24/2011 8:02 AM, Dominic Raferd wrote:
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.


rdiff-backup-users mailing list at address@hidden
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki


Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1498/3524 - Release Date: 03/23/11

reply via email to

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