- 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 why I use rdiff-backup.
Yes, me too, but *inside* the encrypted container.
- If you have disconnection during the rsync step (happened to me last night), your remote backup is temporarily corrupted.Shouldn't rsync do this on its own? There is an option --inplace described with: "This causes rsync not to create a new copy of the file and then move it into place. Instead rsync will overwrite the existing file, meaning that the rsync algorithm can't accomplish the full amount of network reduction it might be able to otherwise (since it does not yet try to sort data matches). One exception to this is if you combine the option with --backup, since rsync is smart enough to use the backup file as the basis file for the transfer. This option is useful for transfer of large files with block-based changes or appended data, and also on systems that are disk bound, not network bound. The option implies --partial (since an interrupted transfer does not delete the file), but conflicts with --partial-dir and --delay-updates. Prior to rsync 2.6.4 --inplace was also incompatible with --compare-dest and --link-dest. WARNING: The file's data will be in an inconsistent state during the transfer (and possibly afterward if the transfer gets interrupted), so
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
you should not use this option to update files that are in use. Also note that rsync will be unable to update a file in-place that is not writable by the receiving user."
Yes, I use --inplace, but it will still leave the remote backup inconsistent in case of an interrupted transfer. And not using it is not an option for a 25GB file (and paying for capacity on the receiving end).
-- Remy
signature.asc
Description: OpenPGP digital signature
