Within a few months we hope to be using Netapp's Snap Manager for Sql Server to "replicate" changes in our production database ( at remote server facility ) to our secondary Netapp filer at our office location. Sql 2005 Enterprise 64-bit
For now I'm thinking of setting up log shipping since I've used it before. There is mirroring but since this is an interim solution I thought I'd stick with what I've used.
Since our entire native sql backup folder on the primary is already being "snapped" to the secondary filer with Netapp tools, I'm wondering if after setting up log shipping I could disable the copy job, and either point the log shipping setup at the folder Netapp is using on the secondary filer, or come up with a job that copies the transaction log backups to where log shipping expects to find them.
Of course the broader question is whether log shipping will hold up when larger indexes are being rebuilt, but the 250MB pipe between the facilities should be able to handle a transaction log backup of 200GB ( largest I've seen) within the 15-minute log backup interval. Rebuilding of such indexes is fairly rare, and we could shorten the log shipping interval.
Everyone boasts about how technology like Netapp's just moves the data blocks that have changed, but with backup files, you're creating a new one ( trn ) every few minutes so I'm guessing it would still have to "snap" the entire file.
Certainly no need to have both Netapp Snap and log shipping copying the same files over this limited bandwidth.