rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Backup not identifyi ng changed file, even thou


From: Patrick Nagel
Subject: Re: [rdiff-backup-users] Backup not identifyi ng changed file, even though hash is different
Date: Sat, 26 Mar 2011 08:27:55 +0800
User-agent: K-9 Mail for Android

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Scott Jilek <address@hidden> wrote:

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

If that TrueCrypt volume is mounted anyway, why don't you just rdiff-backup the 
files inside it into another TrueCrypt volume on the backup system?

Patrick.
Hi Scott,
- --
Sent from my phone.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iG4EAREIAC4FAk2NMwsnHFBhdHJpY2sgTmFnZWwgPG1haWxAcGF0cmljay1uYWdl
bC5uZXQ+AAoJEMmB5oaG40bUImkAoJAl3ci1fMZyzTy8VUVYTsTIbUk4AJ9vTmEq
eybRuyRJFt0hE2Wk10YUmQ==
=5JAW
-----END PGP SIGNATURE-----




reply via email to

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