Step-by-Step: Rsync to Local USB

Thanks for the response! As I learn more, I will update the original post at the top of the thread….

ewok wrote:
bspachman wrote: One says that the source should be a 'remote: rsync server' the other says that the destination should be an 'rsync server'. It's not clear if both methods work, or if one is preferred over the other. Both will work.

Understood, however, is one more advantageous than the other? Consider one likely case: where a user wants to do a partial backup of a share. Does the SOURCE have to be the rsync entry so that the exclusion feature can be used? What happens if you 'exclude' on an rsync destination?

ewok wrote:
The exclusion list is passed directly to the rsync command line. Consult the documentation for rsync (not ReadyNAS specific) for details.

Is it sufficient to look at the man page for rsync on my OSX machine? How is it passed? via the "--exclude" option? My documentation says that it only takes one rule/pattern…. If I want to exclude all transport stream and MPEG files from the backup, can I use "*.ts,*.mpg"?

ewok wrote:
bspachman wrote: 4a) Set up the Source: * Source as Rsync Server? * Host: localhost? 127.0.0.1? the name of the ReadyNAS? the IP address of the ReadyNAS? -- all options seem to give me "Error connecting to xxxx" Any of those should work as long as the path is correct.

It seems that you are right when you actually run the backup job, however, when I click "Test Connection" with any of the above entries in the host field, a pop-up appears telling me that the connection failed.

ewok wrote:
bspachman wrote: * how does the 'remove deleted files on source' option function? If your destination is an rsync share, files that no longer exist on the source will be deleted on the destination.

So does the option apply at all if you are using rsync as a source? If it applies, what happens? For the destination, it would seem to be clearer language to say "remove files already deleted from source" or if it applies in either case, just "Remove deleted files from backup"

ewok wrote:
bspachman wrote: * Note: the hours are when it will begin trying to trigger, and when it will stop trying. This is important if you have multiple jobs scheduled. If Job1 continues past the END TIME of Job2, then Job2 will never trigger. Not necessarily. If a job is triggered while another is running, it will get queued.

So what's the purpose of having an end time for any of the jobs? Something else I had read here on the boards tried to explain the utility of the end times, but I guess I didn't grasp it.

Thanks,
Brad