[gentoo-user] Re: Encrypted backups under Gentoo

[Remy Blank]

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