Re: [rdiff-backup-users] Backup not identifying changed file, even though hash is different

[Scott Jilek]

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.