Neil Bothwick wrote:
>>  - If your local backup becomes corrupt, then so does your remote
>> backup, except if you are quick enough to disable the rsync step.
>
> That's a potential problem with any form of backup, local or remote. The
> truly paranoid would use two different backup methods on two physically
> separate destinations.

Well, it's not quite the same. In the 2-step case (local backup, e.g.
using rdiff-backup, followed by an rsync of the backup to a remote
location), if your local backup gets corrupted, then so does your remote
one.

If you just do two independent backups, even with the same method, one
locally and the second remotely, if one gets corrupted, chances are the
other one is still ok.

>>  - If you have disconnection during the rsync step (happened to me
>> last night), your remote backup is temporarily corrupted.
>
> That should be fixable by having the script that runs rsync check the
> return value and try again if it fails.

You're right, of course. I would still be more comfortable keeping the
"window of vulnerability" (the time for which the remote file is
inconsistent) as small as possible, and independent of network
connectivity. That's why I was thinking in the lines of "calculate diff,
send diff and store remotely, update remote copy when connection has
closed".

-- Remy