> 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