March 21, 2011 at 2:30 pm
I have been trying to find a low cost way to implement DR for our production SQL Cluster (active \ passive). We have 4 SQL 2005 instances and 1 SQL 2008 instance running on the cluster. I've already built a DR server with all of these instances (different server name, but same instance name) and set each instance to run on the same TCP\IP Port as what is currently in PROD. Most of the solutions on this cluster have longer RTO's (2-7 days), so here is what my thought was:
1. Start each instance in single-user mode and restore the master, model and msdb databases.
2. Restart each instance into normal mode and then restore each of the user databases from the previous nights backup (our RPO's are 24 hours) as the actual SQL backups are mirrored over to our DR site every few hours
3. I would modify the DNS entries for each of the PROD cluster virtual servers to point to the IP address of our DR server
4. Begin testing each solution
The other question I have is could I go ahead and test the system DB restores even if the PROD instances are still online? I just wanted to validate the scripts I've written for starting SQL in single user mode and restore the system DB's work without affecting the PROD instances that are still online. I think that should be fine as even after restoring the system DB's, the DR box will still be responding to queries against the DRServerName\InstanceName. It will only start responding to queries against the PROD virtual server name when I change the DNS entries.
Lastly, we are running SQL Server 2005 \ 2008 Standard edition and most of these DB's are all in Simple recovery mode. We've looked at log shipping and other DR products like NSI Double-Take (use it on other more critical systems), but given the RPO \ RTO's along with the edition of SQL we're running, we felt this would be an easy solution for us since most DB's are in the range of 500MB to 3GB.
Thanks!
March 26, 2011 at 6:30 am
Have you looked at mirroring? It could be used to keep the user databases on the DR server up to date rather than having to manually restore each database. There would be considerations around keeping logins, jobs etc in sync but it may be easier to manage and quicker to recover.
However, if you have long RTOs and have tested that the current procedure is acceptable then that is a solution you could use. You can test the restores without affecting the production server as long as there are no jobs, linked servers, openquerys etc as they could probably connect across to the live server using the dns name or ip address that is stored in them.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply