While
tar over ssh is ideal for
making remote copies of parts of a filesystem,
rsync
is even better suited for keeping the filesystem in sync between two
machines. Typically,
tar
is used for the initial copy, and rsync is used
to pick up whatever has changed since the last copy. This is because
tar tends to be faster than
rsync when none of the destination files exist,
but rsync is much faster than
tar when there are only a few differences
between the two filesystems.

To run an
rsync over ssh,
pass it the -e switch, like this:

root@rover:~# rsync -ave ssh greendome:/home/ftp/pub/ /home/ftp/pub/

Notice the trailing / on the file spec from
the source side (on greendome.) On the source specification, a
trailing / tells
rsync to copy the contents
of the directory, but not the directory itself. To include the
directory as the top level of whatever is being copied, leave off the
/:

root@village:~# rsync -ave ssh bcnu:/home/six .

This will keep a copy of the ~root/six/
directory on village in sync with whatever is present on
bcnu:/home/six/.

By default,
rsync will only copy files and directories,
but not remove them from the destination copy when they are removed
from the source. To keep the copies exact, include the
--delete flag:

Now when old reports are removed from
~one/reports/ on greendome,
they're also removed from
~six/public_html/reports/ on jammer, every time
this command is run. If you run a command like this in
cron, leave off the v
switch. This will keep the output quiet (unless
rsync has a problem running, in which case
you'll receive an email with the error output).

Using ssh as your transport for
rsync traffic has the advantage of encrypting
the data over the network and also takes advantage of any trust
relationships you already have established using
ssh client keys. For keeping large, complex
directory structures in sync between two machines (especially when
there are only a few differences between them),
rsync is a very handy (and fast) tool to have at
your disposal.