I'm not a very good teacher, so I'm probably going to go about this all wrong.
When you read that Wikipedia page or the "any number" of other materials on rsync on Google, you're absolutely right that they are pretty consistent and that methods of using rsync are pretty much common knowledge. I'm a grizzly neck beard and I prefer to do things Ye Olde Fashioned way by reading the man page, so that's what my examples will refer to.
- Code: Select all
You use rsync in the same way you use rcp. You must specify a source and a
destination, one of which may be remote.
One of the interesting things that apparently you're not aware of is that rsync doesn't need to be using another system at all. Rsync doesn't care if a group of files is local, presented by a ReadyNAS, living on an EMC iSCSI monstrosity or a microwave oven.
In some cases such as very high-latency low-bandwidth links between two locations, you will want to have that rsync "client/server" relationship, if not as a daemon or service on the remote end, at least to do the calculations and comparisons to avoid transferring the whole file back and forth over that slow connection. This is what rsync was really built for originally. Even if you don't connect over the rsync service, you can use ssh to connect to a remote host and then use the other end's rsync software and only shuffle over the bits that you need to.
- Code: Select all
You can also use rsync in local-only mode, where both the source and des-
tination don't have a ':' in the name. In this case it behaves like an
improved copy command.
In a situation like mine, where the CPU would be the limiting factor, I can (or rather, should be able to if the ReadyNAS worked as designed) move the contents of filesystems over the wire faster than the SPARC can compute hashes on large files (in my case backed up snapshots of a VMWare VM) and figure out which differences there are in rsync. My workstation will be the system conducting the comparisons of the two files. I have the filesystems presented by my ReadyNAS mounted locally, and as far as rsync would be concerned, they're a "local file" if I don't tell it otherwise.
This is pretty common use, since rsync can smartly copy things from Directory A to Directory B, respecting metadata, permissions, and only copying over the things it needs to. Doing it this way puts all of the computational load of the comparison of the SOURCE and DESTINATION, but my workstation doesn't even notice it since it's ample (i7 2600k @4GHz). By using --progress and --partial, I can recover from an interrupted copy and also see how much throughput I've got. That's how I know how slow it is to write to and read from my ReadyNAS over the network and how I can test multiple protocols (NFS/AFP) so easily.
I am very familiar with the computational limitations of the SPARC family of CPUs. I ported SETI@Home to sun4c and sun4m on two BSD distributions and was the port maintainer of those and m68k for a little while Back In The Day™. That is why I don't put the load of calculating file checksums on the ReadyNAS NV+, it clearly has enough to worry about.
Hopefully this illustrates things better and now you can go forth and use the mighty rsync in new ways, like the developers intended!