October 14, 2012 at 4:14 pm
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.
October 15, 2012 at 5:37 am
The log shipping meta data keeps a trcak of files copied and restored. Start messing with the plan itself and it will likely fail. If you want to run LS run it as a separate plan.
If using snapmanager create a set of scripts that will restore the files for you
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
October 15, 2012 at 5:43 am
Yes it might be easier to just leave our current native sql backups in place for now on the primary, restore a copy of the database on the standby filer ( in either recovery or standby mode), and hand craft some restore scripts. These scripts would need to either determine which trn files in a Netapp "snap" folder are to be restored and possibly move trn files to another folder after restore to avoid failed restore attempts.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply