Advice on bringing up second SQL server as a standby. Primary runs SnapDrive & SnapMirror...
3 weeks ago
TL;DR: Do we need to build an exact replica of our DB server if we're planning on using the secondary as a standby. We currently use SnapManager/SnapDrive as our SQL backup solution. This question also assumes the "main" DB server is dead or exploded in pieces.
Now for the gory details. Management would like to eliminate this single point of failure by having an exact up-to-the-minute backup of our Production DB server. They won't get that, as far as I know Windows Server 2008R2 and SQL Server 2008 don't support clustering per se, and to upgrade it to 2016 would require a lot of (wo)man hours converting and testing the code that has accumulated over years.
So, in the short term we were thinking of bringing up a much-less-powerful MSSQL Server and do log shipping. The backup would only be for the purposes of running a minimal business-needs SQL server until another could be spun up.
We run both SnapManager for SQL and SnapDrive on the DB server now, and we're not considering moving away from that solution. It does a good job. But, does that lock us into building an exact replica, meaning it would be set up with its famous insatiable requirements for CPU, RAM and storage.
I did search The Google and The Forums, right here at cozy NetApp.) I've read several different sources that say not to mix SnapManager with 3rd party software, and I've seen slightly less articles saying it can be done. I couldn't really ask a NetApp support rep to offer advice on an unsupported kluge. Unless I deny recording the call......maybe.....
In any case, as it stands, I fear were headed toward the inevitable direction that we need to set up a near-mirror as a warm spare. To that end, I had several questions I asked NetApp support, and was admonished because it wasn't asking about a technical problem, so they don't handle that. Fair enough. I'll put it to the public.
- Can we restore a snapmanager backup to a different server?
- Can we simply detach the LUNs on the (presumably failed) primary and attach them to the backup server. I'm fairly certain you can't mount a LUN in two different places, we use RDM if that makes any difference.
- What is the effect of full recovery mode in SnapManager 7.2.2? We backup with Simple Mode because SnapManager requred it. Or that's just how they set it up, I wasn't here back then. Can we convert those to full backup, or is that still off-limits?
- If a LUN becomes inaccesible or corrupt, is the volume still available to mount to another LUN?
I have more, but this post is already long enough. Just want a starting point and we'll figure out how to proceed once we know the limitations or hidden implementations we didn't know about. Feel also to post if you have any general advice about a similar scenario, if it isn't directly related to ours. It's just good to know. I mean, it's not like we're working or anything, right?
1 REPLY 1
Re: Advice on bringing up second SQL server as a standby. Primary runs SnapDrive & SnapMirror...
3 weeks ago
Restoring on remote server is completely supported. further more. snapmanager has built in mechanism to test the restore on the remote server after each backup (it's get mounted on temp mount point and loaded to SQL).
it's seems to support iSCSI/FC LUNS, SMB Shares and VMDK. however i don't see if RDM is supported (i believe it is). needs to check it against the specific version and ontap mode documentation.
https://www.netapp.com/us/media/tr-4369.pdf - SMSQL 7.2 Cdot best practices
https://www.netapp.com/us/media/tr-4232.pdf - SMSQL 7.0 7-mode best practices
i believe that's kind of answer your two first questions. not sure what the answer for the others