Rsync directly from the target would be more efficient. I've never been able to make this work using cygwin sshd on the windows side to accept the connection and run rsync, but that could be a bug that is fixed now. It will work using rsync in daemon mode on the windows side, or initiating the connection from windows to a Linux target via ssh.
If you don't want the whole cygwin setup on your machines, there is a minimal install for rsync here: http://sourceforge.net/project/showfiles.php?group_id=34854
I can't install cygwin or a daemon for that matter on the Windows Server, but I could execute a scheduled job to run a Widows port of rsync on the file server which I am not opposed to at all. My only problem with that is how do I then trigger the Bacula server to begin the dump to tape once the sync is complete?
I need an additional replica of the data, so using the Windows Bacula client
doesn't help,
I thought bacula could be configured to keep both an on-line and tape copy.
Possible, but I wouldn't have time for it to dump all the data if it simply accessed the CIFS share to copy all the data.
and I must be able to only replicate the changes or I'll miss my backup
window based on the volume of data.
I use backuppc to keep an online and easily accessible history and amanda for tapes that go offsite (and I hope to never have to recover from the amanda tapes because it is much more difficult) and I just let them run independently. If your backup window is tight, you might have to run both (or bacula) against your rsync-mirrored snapshot instead of the actual target. This works well for data files but you'll need some extra contortions if you expect to do bare metal restores of the windows targets.
Yea, bare metal is handled elsewhere, I just need file level protection. Not sure about Backuppc, it still doesn't help me trigger Bacula as soon as the sync is complete.
Thanks for the help! jlc