[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 18:01:02 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

On 3/24/2011 3:42 PM, Chris Wilson wrote:
Hi Scott,

On Thu, 24 Mar 2011, Scott Jilek wrote:

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

In that case, rdiff-backup probably won't be able to open it to back it up either? You'll probably get an error message that the file can't be opened when you try to back it up? And even if you could back it up, you'd probably get an inconsistent and hence useless/corrupt backup if truecrypt is really writing to the encrypted filesystem while a backup or rsync is in progress.

Correct, I am utilizing Volume Shadow copies to get around the file locking. I tried using a windows compiled touch, but it wouldn't work on the Truecrypt volume while it was mounted (which is why I started with VSS in the first place).
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

You could rsync the truecrypt file to somewhere else, if that works, and then back it up with a separate rdiff-backup command?

Or alternatively create a VSS snapshot and back that up? But Truecrypt would probably need to be patched to be a VSS writer, or to not reset the timestamp when it writes to the file, because you probably can't change the timestamp in the VSS snapshot, it being a snapshot and hence read-only.

I was thinking along those same lines and planning to mess with that approach tonight. In my backup script, I figured I'd 1) take a VSS snapshot of truecrypt file, 2) make a copy of the truecrypt volume file from the VSS snapshot to some temporary location, 3) touch that copied file & 4) run an rdiff-backup command targeted only on that temp file.

This process would be a bit of a hack, but I think it *should* work. The downsides are it temporarily takes up some free space, and extra time in write cycles, but if it works, I can live with it. Granted, disc space is cheap & the backup runs over night, but I was just hoping to let Rdiff handle everything.

Cheers, Chris.

reply via email to

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