Backup encryption key

[Shachar Shemesh]

Yuval Hager wrote:
>
> Thanks. I probably wasn't clear on (5). I would like to be able to go back 
> in time when I restore. AFAIK, rsync* solutions are mirroring the current 
> state only, where rdiff-backup and duplicity does allow time travel.
>
> There is still the original question about the key handling, I just wanted 
> to give a little more context..
>
> --y
>   
rsync allows you to create a new image for each iteration, where the new 
version contains hard links to the old one if nothing changed in the 
file. For all intents and purposes, this is incremental backup.

I should point out one huge disadvantage of storing binary diffs when 
using encrypted systems. There is no (practical) way to erase old 
backups. Your backup storage size is bound to be ever increasing. This 
is because the only way to create a new complete snapshot (i.e. - a 
non-incremental backup) is to retransmit the entire backup data. Because 
the remote side is encrypted, you cannot use it to expand the image 
remotely.

With rsync, you have some storage overhead (changed files are stored 
again in their entirety, rather than merely the changes), but that does 
not reflect in the bandwidth requirement. You gain the advantage that 
every snapshot is independent. You can erase old snapshots in arbitrary 
order, without risking your data.

Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20090423/3cb14f8e/attachment-0001.html>