I'm trying to set up a backup/mirroring system for my home LAN. I
want all the computers to mirror certain directories to a "server"
machine using rsync.

A lot of the web sites out there explaining how to do this kind of
thing use inetd on the server to create an rsync daemon. However,
I'm not clear what the advantage is of using an rsync daemon over
just using rsync directly on the client machines with ssh as the
transport. Setting up the daemon seems to be an extra complication,
without any advantage I can discern. Yet, many of the web sites
don't even discuss the alternative, as if it were obvious that
using the daemon were the right approach.

Am I missing something?

On Wed, 19 Mar 2008 00:10:10 -0600, "Jim T. Kirk" <captain@starshipenterprise.com> wrote:

>I'm trying to set up a backup/mirroring system for my home LAN. I
>want all the computers to mirror certain directories to a "server"
>machine using rsync.
>
>A lot of the web sites out there explaining how to do this kind of
>thing use inetd on the server to create an rsync daemon. However,
>I'm not clear what the advantage is of using an rsync daemon over
>just using rsync directly on the client machines with ssh as the
>transport. Setting up the daemon seems to be an extra complication,
>without any advantage I can discern. Yet, many of the web sites
>don't even discuss the alternative, as if it were obvious that
>using the daemon were the right approach.

You could NFS export / mount filesystems and use rsync directly
for the localnet file transfer/backup task.

Grant.
--
http://bugsplatter.mine.nu/

Jim T. Kirk wrote:
> I'm trying to set up a backup/mirroring system for my home LAN. I
> want all the computers to mirror certain directories to a "server"
> machine using rsync.
>
> A lot of the web sites out there explaining how to do this kind of
> thing use inetd on the server to create an rsync daemon. However,
> I'm not clear what the advantage is of using an rsync daemon over
> just using rsync directly on the client machines with ssh as the
> transport. Setting up the daemon seems to be an extra complication,
> without any advantage I can discern. Yet, many of the web sites
> don't even discuss the alternative, as if it were obvious that
> using the daemon were the right approach.
>
> Am I missing something?

You need to run a rsync daemon on the server in any case; your choice is
whether to have it running all the time (from startup) or to be invoked
by inetd when an rsync client connects.

Robert

On Wed, 19 Mar 2008 00:10:10 -0600, Jim T. Kirk wrote:

> I'm trying to set up a backup/mirroring system for my home LAN. I
> want all the computers to mirror certain directories to a "server"
> machine using rsync.
>
> A lot of the web sites out there explaining how to do this kind of
> thing use inetd on the server to create an rsync daemon. However,
> I'm not clear what the advantage is of using an rsync daemon over
> just using rsync directly on the client machines with ssh as the
> transport. Setting up the daemon seems to be an extra complication,
> without any advantage I can discern. Yet, many of the web sites
> don't even discuss the alternative, as if it were obvious that
> using the daemon were the right approach.
>
> Am I missing something?

There is overhead ( and security ) by using rsh over ssh.

If you use rsyncd, it's faster ( non-ssh ) and you can do
things like list rsync directoy resources. I think that you
can mark things as ro too. rsyncd is more for apps that have
multiple users accessing the server.

I use rsync over ssh for 99% of my stuff.

jack

--
D.A.M. - Mothers Against Dyslexia

see http://www.jacksnodgrass.com for my contact info.

jack - Grapevine/Richardson

Robert Harris <robert.f.harris@blueyonder.co.uk> wrote:
> You need to run a rsync daemon on the server in any case; your choice is
> whether to have it running all the time (from startup) or to be invoked
> by inetd when an rsync client connects.

Actually, you don't have to have rsyncd running on the server if you
use ssh as the transport and the rsync binary in the user's path. My
users routinely slog tons of data across our network without me having
to setup rsync repositories for them.


Mike

--
Michael Zawrotny
Institute of Molecular Biophysics
Florida State University | email: zawrotny@sb.fsu.edu
Tallahassee, FL 32306-4380 | phone: (850) 644-0069

Michael Zawrotny wrote:
> Robert Harris <robert.f.harris@blueyonder.co.uk> wrote:
>> You need to run a rsync daemon on the server in any case; your choice is
>> whether to have it running all the time (from startup) or to be invoked
>> by inetd when an rsync client connects.
>
> Actually, you don't have to have rsyncd running on the server if you
> use ssh as the transport and the rsync binary in the user's path. My
> users routinely slog tons of data across our network without me having
> to setup rsync repositories for them.
>
>
> Mike
>
Ah - but rsync on the server is run in daemon mode as rsyncd while it is
talking to your rsync client. The transport is the data transport; rsync
on the client figures out what needs transporting by comparing notes
with the rsync daemon on the server.

Robert

Robert Harris <robert.f.harris@blueyonder.co.uk> wrote:
> Michael Zawrotny wrote:
> > Robert Harris <robert.f.harris@blueyonder.co.uk> wrote:
> >> You need to run a rsync daemon on the server in any case; your choice is
> >> whether to have it running all the time (from startup) or to be invoked
> >> by inetd when an rsync client connects.
> >
> > Actually, you don't have to have rsyncd running on the server if you
> > use ssh as the transport and the rsync binary in the user's path. My
> > users routinely slog tons of data across our network without me having
> > to setup rsync repositories for them.
> >
> Ah - but rsync on the server is run in daemon mode as rsyncd while it is
> talking to your rsync client. The transport is the data transport; rsync
> on the client figures out what needs transporting by comparing notes
> with the rsync daemon on the server.

That's one way to do it. If you "rsync -av server::some_module ." it will
copy the contents of the defined module from rsyncd on the server to
the current directory. On the other hand, "rsync -av server:my_dir ."
will copy $HOME/my_dir and all of it's contents to the current
directory. In that case, there is no rsyncd on the server, the user
has to have login priveleges on the server and rsync has to be able to
be found in $PATH. The difference is how you specify the remote
location, one ":" or two.


Mike

--
Michael Zawrotny
Institute of Molecular Biophysics
Florida State University | email: zawrotny@sb.fsu.edu
Tallahassee, FL 32306-4380 | phone: (850) 644-0069

Michael Zawrotny wrote:
> Robert Harris <robert.f.harris@blueyonder.co.uk> wrote:
>> Michael Zawrotny wrote:
>>> Robert Harris <robert.f.harris@blueyonder.co.uk> wrote:
>>>> You need to run a rsync daemon on the server in any case; your choice is
>>>> whether to have it running all the time (from startup) or to be invoked
>>>> by inetd when an rsync client connects.
>>> Actually, you don't have to have rsyncd running on the server if you
>>> use ssh as the transport and the rsync binary in the user's path. My
>>> users routinely slog tons of data across our network without me having
>>> to setup rsync repositories for them.
>>>
>> Ah - but rsync on the server is run in daemon mode as rsyncd while it is
>> talking to your rsync client. The transport is the data transport; rsync
>> on the client figures out what needs transporting by comparing notes
>> with the rsync daemon on the server.
>
> That's one way to do it. If you "rsync -av server::some_module ." it will
> copy the contents of the defined module from rsyncd on the server to
> the current directory. On the other hand, "rsync -av server:my_dir ."
> will copy $HOME/my_dir and all of it's contents to the current
> directory. In that case, there is no rsyncd on the server, the user
> has to have login priveleges on the server and rsync has to be able to
> be found in $PATH. The difference is how you specify the remote
> location, one ":" or two.
>
>
> Mike
>
Yes, you are right.

Robert

On 2008-03-19, Jim T. Kirk <captain@starshipenterprise.com> wrote:
>
> A lot of the web sites out there explaining how to do this kind of
> thing use inetd on the server to create an rsync daemon. However,
> I'm not clear what the advantage is of using an rsync daemon over
> just using rsync directly on the client machines with ssh as the
> transport.

The main advantage is hosting a public rsync repository where the
clients do not necessarily have a shell account on the server, similar
to hosting an anonymous ftp download site.

--keith


--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Robert Harris <robert.f.harris@blueyonder.co.uk> writes:

>Michael Zawrotny wrote:
>> Robert Harris <robert.f.harris@blueyonder.co.uk> wrote:
>>> You need to run a rsync daemon on the server in any case; your choice is
>>> whether to have it running all the time (from startup) or to be invoked
>>> by inetd when an rsync client connects.
>>
>> Actually, you don't have to have rsyncd running on the server if you
>> use ssh as the transport and the rsync binary in the user's path. My
>> users routinely slog tons of data across our network without me having
>> to setup rsync repositories for them.
>>
>>
>> Mike
>>
>Ah - but rsync on the server is run in daemon mode as rsyncd while it is
>talking to your rsync client. The transport is the data transport; rsync
>on the client figures out what needs transporting by comparing notes
>with the rsync daemon on the server.

No.
That is only one way you can do it.
If you do
rsync remote.machine.com:/path/to/file /local/path/
then rsync will log onto the remote machine with ssh, start up an ordinary
rsync there to talk to the local rsync. No daemon involved anywhere.