Take2: rsync over ssh with --link-dest

Matt McCutchen matt at mattmccutchen.net
Sun Nov 8 22:48:41 MST 2009

On Mon, 2009-11-09 at 00:28 -0500, Alex wrote:
> >> I'm a bit disappointed that I
> >> can't do it by overriding the server command line
> >
> > Why?  Does it have some advantage over the use of an rsync daemon (I
> > can't imagine what)?  One can't really expect overriding the server
> > arguments not to lead to the inconsistent behavior you saw.
> Simplicity. I'd like to be able to have the server side feed me all
> data beginning with the path I specify, such /backup/serverA,

In other words, you were specifying a bogus source path and counting on
sshd to override it with the real one.  Clever.  I didn't catch that the
first time.

Realize that the ability to set a module's "path" in the rsyncd.conf
file and have the client refer to the module by a well-known name gives
you the same functionality, and actually more, because the client can
specify a subdirectory path within the module.

> and have
> the client side be able to "--include=/usr/bin" to be able to
> 'download' only the data from /backup/serverA/usr/bin and exclude
> everything else.

That --include means "exclude everything else" is a common
misconception; see the man page.  But I imagine the issue will become
moot if you have the client specify a subdirectory of the module instead
of using filters.

> Instead, I have about eight sections of my rsyncd.conf to do this; one
> for each directory tree that I want to back up to a different
> location, primarily based on dates, to have multiple incrementals.

If the daemon solution is looking fundamentally more complicated than
the set of forced server commands you previously had, you're probably
going about it the wrong way and I could help if you post the
rsyncd.conf file.


More information about the rsync mailing list