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

[Chris Wilson]

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.

> 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.

Cheers, Chris.
--
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <address@hidden> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |