2012-03-07 07:54 AM
I am currently using the integration of SnapManager with Protection Manager that allows me to create a dataset of the volumes that contain my user databases. This give me an option within Snapmanager to have not just local backup, but archive backup also. My question is how come it does not include the system databases? Currently we have a separate lun for the system databases
F: is a LUN for system db and log
G: is a lun for user db
L: is a lun for user log
S: is a lun for Snapinfo
G, L and S get included in the dataset, except F.
I am trying to arrive to a point that we can fully restore the database server on our DR site. I have a snapshot of the db server (which is a VM through SMVI), so I also have G, L and S. But I don't have F which contains the system db. Would it be better to just leave the system dbs in C drive?
2012-03-07 08:25 AM
Assume we're talking SnapManager for SQL, right?
It doesn't snapshot the system database LUN, but uses stream-based backup to backup the system DB's to the SnapInfo LUN (S.
2012-03-08 07:33 AM
I would imagine so, yes, although I've never tried this outside of SMSQL. Essentially, snapmanager will recover the system db's from the snapvault archive via Protection Manager's integration.
2012-03-08 09:27 AM
has anyone ever tried this in the described scenario? In a DR situation, the DR site can boot up the SQL server VM (the OS). But SQL Server instance will not be able to start because of the LUN hosting the System DBs is missing, right?
Is it really possible (tested?) to do a snapmanager restore of system DBs onto a not-running SQL instance?? I assume a freshly created empty "SystemDB LUN" F: before the restore job.
I've also never tested this - but am not sure if this will work.
An different approach would be to have a seperate DR SQL server instance on the DR site, which is up and running with it's own set of system DBs... SMSQL could then restore only the user DBs to this DR server.
But this of course requires changes to all application servers / user connections to SQL, because the SQL server hostname would be different at the DR site...
My personal approach at the moment is to create another "manual" dataset (non-SnapManager dataset) that includes all "System DB LUNs" of all primary SQL instances and vaults/mirrors them to the DR site, because SnapManager does not do it for me... of course this is more or less "crash consistent", but worked fine during my DR testing.
So - good question - has anyone tried the scenario without replicating the original server's system DBs? Can the SnapManager "stream" backup (master, model, msdb) be restored to a "down" Sql server?
2012-03-08 10:15 AM
I am about to go to the same route that you already are doing, which is to create a separate relationship just for the volume containing the system dbs. My concern was that it may not be a consistent backup since the system db will not be on the quiesced state. But are you saying it works for you? Then that is good news to me.
I can see in the Snapinfo folder, just like Gardinec said, that there is a full stream backup of system dbs. The question is how to restore them?
2012-03-09 07:58 AM
If you go to SnapManager- Restore. On the Actions, select Find Backups.
On the wizard, hit next on welcome.
Select “Restore from “Unmanaged media”. Next
Next step allows you to browse to the snapinfo folder. It says that you have to copy the snapinfo folder to the machine. I guess that would mean attacing the archive lun of snapinfo to the server which we want to recover.
I have not got the chance to test it yet but it seems like this is close to what we are looking for.
2012-05-11 12:47 PM
I'm getting close to testing this out as well. Will work on providing a response when I get done.
Thanks for clarifying that the system db disk will not mirror. That was driving me nuts for a bit there .