<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

</head>

<body dir="ltr" bgcolor="#ffffff" text="#000000">

Yuval Hager wrote:

<blockquote cite="mid:200904231640.31876.yuval@avramzon.net" type="cite"><br>

  <pre wrap="">

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

  </pre>

</blockquote>

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

<br>

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

<br>

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

<br>

Shachar<br>

<br>

<pre class="moz-signature" cols="72">-- 

Shachar Shemesh

Lingnu Open Source Consulting Ltd.

<a class="moz-txt-link-freetext" href="http://www.lingnu.com">http://www.lingnu.com</a>

</pre>

</body>

</html>