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
signature.asc
Description: OpenPGP digital signature
