Re: Remote rsyncrypto

[Colin S. <Col...@io...>]

I'll try a test and see if I can measure the approximate bandwidth
used.

Thanks

Colin


On Mon, 2016-11-21 at 23:42 +0200, Shachar Shemesh wrote:
> On 21/11/2016 19:42, Colin Simpson wrote:
> >
> > So backing up via SSH would be my preferred method. The suggested
> > way
> > from the previous thread was use rsyncrypto to another and sync
> > this
> > via rsync. But I just don't have a spare 8TB lying around.
> >
> > Has it been tried to run this via say, sshfs? Would that work?
> >
> I have no idea how sshfs works, so I don't know. If I were to guess,
> I'd say that files that have not changed would work (because
> rsyncrypto doesn't touch them), but files that changed only a little
> might pay the full bandwidth.
> Another complication is that rsyncrypto isn't, strictly speaking, one
> pass. The file header is written only after the encrypted file is
> written. This has its reasons rooted in the use of external utility
> for the compression (Gzip), and the need not to pass it garbage past
> the end of the file. They are not good enough reasons, so I had
> planned a new version of rsyncrypto that would be able to work as a
> filter. Had that been around, you could filter it to librsync, and
> get what you wanted. Unfortunately, I don't know what decade I'll
> manage to get around to actually doing it.
> Either way, it is worth a try, and let us know what the results are.
> Shachar
>

________________________________


This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original.