2017-06-10 08:57 AM - edited 2017-06-10 08:58 AM
We are performing a SQL Server disaster recovery test and have realized that the sysdb volume does not get snapmirrored to the DR filer.
Our SQL server is a VM so we will be able to recover the actual SQL Server itself in event of a DR, but its kind of useless if the System Databases have not replicated.
I see in the backup logs that they are configured as streamed backups.
Realistically, the sysdb volume should be snapmirrored along with the userdb and the logs over to the DR filer everytime the backups run.
All the SMSQL guides talk about doing a manaual recovery of SQL and then doing a restore, but I don't/shouldn't need to do that.
It should be as simple as mounting my sysdb volume along with all the other volumes and starting SQL...it will do the rest to recover....
Obviously if I had to recover the SQL server with a new install, that would be a different story, but thats now an exception to the rule, vs a normal configuraiton any longer.
So...is there a way to get SMSQL to actually kick off a LUN snapmirror as part of the regular job or so I have to just run the native snapmirror process and be done with it?
2017-06-13 08:06 AM
id does not seem official practise, but we use the fact that the snapinfo volume become an snashot and replicated with the rest of the virtual sql server to secondary site automaticly.
User DBs and Logs on sperate raw luns.
2017-06-27 01:11 AM
Snapmanager does not Snapshot the System DB.
You can however put the System DB on NetApp Storage and trigger a Snapshot by schedule on the Filer or via post script if needed after the snapmanager Operation completes.
Those snapshots you can then mirror to a secondary location.