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.
-Scott
Cheers, Chris.
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
