|
From: | Dominic Raferd |
Subject: | Re: [rdiff-backup-users] Backup not identifying changed file, even though hash is different |
Date: | Thu, 24 Mar 2011 18:20:08 +0000 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 |
On 24/03/2011 17:31, Scott Jilek wrote:
Unfortunately, I can't just touch the file because it's in use and locked by the truecrypt process.
Are you sure? I tried this and it worked for me with a truecrypt file in use.
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.
rdiff-backup development is stalled, sorry
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
I agree, rdiff-backup is practically perfect. But when you hit a limitation you will have to workaround.
Dominic http://www.timedicer.co.uk
[Prev in Thread] | Current Thread | [Next in Thread] |