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