Backup Central

I'm looking to speed up my rdiff-backups over the LAN interface in our
production environment. How do I force rdiff/rsync to use RSH instead of
SSH? The speed difference is significant and the loss of security is pretty
minimal given that we're only talking to ourselves.

Thanks in advance!


Michael

On Wed, 26 Jan 2005 15:44:24 -0800
"Michael Nguyen" <michaeln < at > twentyten.org> wrote:

I'm looking to speed up my rdiff-backups over the LAN interface in our
production environment. How do I force rdiff/rsync to use RSH instead of
SSH? The speed difference is significant and the loss of security is
pretty minimal given that we're only talking to ourselves.

Hi Michael

In the rdiff-backup man page there is a section headed "REMOTE OPERATION" -
if you view the man page ("man rdiff-backup") then type a slash ("/")
followed by "remote operation" it will take you to the first occurrence of
that string. Typing 'n' will take you to successive occurances, and very
soon you'll come across the section with that name. In there it explains
how to use different schema (ie, methods of connecting to the remote
system).

Hopefully that will help you out.

Keith

From: "Keith Edmunds" <keith < at > midnighthax.com>
On Wed, 26 Jan 2005 15:44:24 -0800
"Michael Nguyen" <michaeln < at > twentyten.org> wrote:

[snip]

In the rdiff-backup man page there is a section headed "REMOTE
OPERATION" -
if you view the man page ("man rdiff-backup") then type a slash ("/")
followed by "remote operation" it will take you to the first occurrence of
that string. Typing 'n' will take you to successive occurances, and very
soon you'll come across the section with that name. In there it explains
how to use different schema (ie, methods of connecting to the remote
system).

Thanks, Keith. I actually read that, but I had no idea what they meant by
"schema" so I sort of ignored it. This sounds like a trivial problem at
this point. Thanks!


Michael

Hi,

Try the --remote-schema option.

Perhaps something like
rdiff-backup --remote-schema "rsh %s rdiff-backup --server"
Although on my system rsh has been replaced with ssh anyway. Or even
just use the --ssh-no-compression option. I don't actually think the
overhead of ssh itself is *that* high.

Alternatively you might find that a samba or NFS would be faster.

Ryan


On Wed, 26 Jan 2005 15:44:24 -0800, Michael Nguyen
<michaeln < at > twentyten.org> wrote:
I'm looking to speed up my rdiff-backups over the LAN interface in our
production environment. How do I force rdiff/rsync to use RSH instead of
SSH? The speed difference is significant and the loss of security is pretty
minimal given that we're only talking to ourselves.

Thanks in advance!

Michael

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Hi,

Try the --remote-schema option.

Perhaps something like
rdiff-backup --remote-schema "rsh %s rdiff-backup --server"
Although on my system rsh has been replaced with ssh anyway. Or even
just use the --ssh-no-compression option. I don't actually think the
overhead of ssh itself is *that* high.

Hmm....well, I don't know if it's valid or not but I ran two tests...one FTP
and one SCP. FTP pushed about 960MB/min. SCP was around 472 MB/min.

Whether FTP and SCP correlate well to RCP/RSH vs. SCP/SSH is unknown to me,
but I *assumed* that it would.

We do these nightly backups of a huge user mail system (using rdiff-backup
of course!) and I'm just trying to gain any edge I can. It started with cp
+ hard links with rsync, then moved to rdiff-backup. Now it's RSH vs. SSH.
It's all about getting my backups to as close to real-time as possible
without spending more money. ;-)

Thanks guys!


Michael

On Wed, 26 Jan 2005, Michael Nguyen wrote:

I'm looking to speed up my rdiff-backups over the LAN interface in our
production environment. How do I force rdiff/rsync to use RSH instead of
SSH? The speed difference is significant and the loss of security is pretty
minimal given that we're only talking to ourselves.

http://arctic.org/~dean/patches/openssh-3.8.1p1-cipher-none.patch

it really annoys me they don't let you shoot yourself if you want to... i
mean even with this patch you have to explicitly enable the None cipher in
sshd_config... (which means that if your host can get non-LAN connections
you really should consider running a none-capable sshd on a different, ip
addr access controlled, port.)

definitely helps on gig-e.

-dean