[geeks] Cheap/reliable backup?

[Mouse]

>>> One thing is for sure, incremental backups based on an encrypted
>>> whole-drive don't make sense.
>> Sure they do.  You just need to use a random-access encryption
>> system.  [...]
> Not that it means anything, but this is the first I've heard of it.
> And if it wasn't you saying it, I wouldn't even bother trying to look
> it up.

There's a page on English Wikipedia "Disk encryption theory" that talks
about this stuff; that might be a decent place to start looking.  (And
thank you very much for the compliment - though I fear you credit me
with more expertise than I have; as a cryptographer I'm strictly a
dilettante.)

>> (At its simplest, consider a block cipher whose block size equals
>> your disk sector size, used in ECB mode.  [...])
> I understand that was just an example, but there aren't any known
> block ciphers with a 512 bit block size AFAIK.

4096 bit.  512 _byte_.  And, yes, I know of none with a native 4096-bit
block either.  But it's not hard to synthesize such a one; to pick a
simple example, consider the 4096-bit block as a 64x64 array and pick a
block cipher with a 64-bit block.  Encrypt each row in ECB, then
encrypt each column in ECB.  If you're willing to manage the extra key
material, use a key 128 times as large and use a separate key for each
of the 128 encryptions - I'm not sure it really makes it as much harder
as it looks, but, because the single-key version is just a special case
of the more general version, it can't make it any weaker, and it does
remove a weakness which appears when the sector contains very
repetitive data (eg, all bytes identical).

> We still can't do an incremental backup of a file, only of an entire
> disk image or partition.

Well, if you're keeping disk-image backups, I would assume incremental
backups would also be at the disk-image level.

> If you're going to work with encrypted incremental backups, it really
> seems like it has to be on the file level to work with the copy tools
> that exist.  I'm sure you could write a script or program to manage
> disk blocks in an rsync-ish way and do that, but I'm not sure how
> flexible that is since the receiver has to have the same size and
> type file system as the sender which is ok but not as useful as it
> could be.

Actually, no.  My own backup paradigm is basically dd images, but the
backup host neither knows nor case what filesystem (if any!) the client
host has in the partition - it just stores the image as a big file in
its own filesystem.  Incremental updates are sent as block contents,
and a resync (eg, after a reboot) does not send the whole disk's
contents over again.  (Currently it sends about 4% as much data as the
disk holds; I have some ideas I need to implement to cut that down in
common cases.)

Of course, this is no immediate practical help to you unless that kind
of incremental is suitable for your purposes, which it sounds as though
it's not.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B