Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Restore System DBs to Another SQL Instance Expand / Collapse
Author
Message
Posted Wednesday, August 11, 2010 2:13 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, July 22, 2011 2:04 PM
Points: 64, Visits: 164
Hi and thanks for reading my post. Here's my scenario...

We're working on a DR scenario where we would take ALL our nightly backup files (system and user) from our production sql server 2005 database and then restore them onto a brand new (no user databases) instance of sql server 2005. We have a cluster so this is just worst-case scenario where we would have to completely rebuild the production database.

Now we've been working on restoring the system databases first (of course) to the new instance and came up across this problem. Our production server has 2 drives - k: for data files and l: for log files. Our test box for the restores is set up with only a c: drive.

So you guessed it - it's been a nightmare trying to restore the master database. Restored it, but then I got errors that the system couldn't find the data and log files for mssqlsystemresource (because of course they were pointed to k: and l: drives that didn't exist). OK, so I corrected that with an alter database command. Then I got the same message for model - and then for tempdb and so on...

Suffice to say, we still can't get the test instance to start up. Now I'm getting an error message about the service broker being down and the need to bring msdb online. I can start the sql service - but NOT the sql agent service.

After restoring and fixing (I thought) all the system DBs, when I again tried to start up the instance in single user mode, I got a TON of error messages stating that the system could not open up all our user database files (that don't exist yet because we haven't restored them yet) because again, the system was looking for a k: and l: drive that didn't exist.

I'd love to hear from everyone their take on what's the best approach to tackle this. Is it worth going through all this and if it is, how do I get out of this mud-pit? Also, if we were to simply get a test box with the exact hardware configuration as our production box (with k: and l: drives), would this eliminate all these issues and make the process easier?

A big thank you in advance to all who reply. I'm new to the DBA role so any tips are MUCH appreciated.
Post #967807
Posted Wednesday, August 11, 2010 5:23 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:43 PM
Points: 5,365, Visits: 8,965
You are going through a very rough way of doing this.

I'd not worry about the system databases. Instead, I'd worry about the data in them that is needed to bring your DR system up.

I'd suggest establishing a migration policy where:
1. Any changes to the production server model database also needs to be done on the DR server model database.
2. All SSIS pkgs and jobs deployed to the production server need to be deployed to the DR server, but disabled. (IMO, the SSIS pkgs should use configuration files to be able to run on either server without issue.)
3. Any custom user messages added to the system need to be added to both servers.
4. Any server objects (linked servers, etc.) need to be added to both servers.

I would also utilize a SSIS transfer user task to frequently transfer all users from the production server to the DR server. If I remember correctly, there might even be a task to transfer system messages. These could be on either server; if on the DR server, then these should be about the only enabled jobs you have.

Oh... it would be wise to make your DR server identical to your production server, if at all possible. Ideally (IMO), same model, same configuration, serial numbers differ by only 1.


Wayne
Microsoft Certified Master: SQL Server 2008
If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!
Links: For better assistance in answering your questions, How to ask a question, Performance Problems, Common date/time routines,
CROSS-TABS and PIVOT tables Part 1 & Part 2, Using APPLY Part 1 & Part 2, Splitting Delimited Strings
Post #967878
Posted Wednesday, August 11, 2010 5:35 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, July 22, 2011 2:04 PM
Points: 64, Visits: 164
HI and thanks so much for your reply. Yes, this is a very rough way to go about this and it's been a very unpleasant experience. I guess we have no choice but to configure the DR server as a cluster as well? Anyone else have any other suggestions? Thanks again!
Post #967884
Posted Thursday, August 12, 2010 1:26 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, May 29, 2011 9:01 AM
Points: 211, Visits: 4,106
dso808 (8/11/2010)
HI and thanks so much for your reply. Yes, this is a very rough way to go about this and it's been a very unpleasant experience. I guess we have no choice but to configure the DR server as a cluster as well? Anyone else have any other suggestions? Thanks again!


The DR server does not need to be a cluster.
However, you should create the same objects(Linked Servers, Users, Job Mail Profiles, Jobs(Disabled), SSIS packages) in both the places. In case you loose your main server, you will have most of the content already in the DR Server.
this will help you and would not really need the system databases to be restored.
For the user databases, you can use the backups to restore them.
Post #967966
Posted Thursday, August 12, 2010 1:00 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, July 22, 2011 2:04 PM
Points: 64, Visits: 164
Hi and thanks so much for your help. Your suggestion sounds like the most feasible solution for our situation. We've also thought of perhaps setting up the DR server to mirror our user databases, recreate all logins, jobs, maintenance plans etc onto the DR server, and then make procedures so that going forward, all changes to our production server (the cluster) are also made to the DR server.

But lesson learned. System database backups from a cluster should only be restored onto that cluster - NOT to another instance. Especially into an instance in a non-clustered environment.

Any one else have input? Anyone else have a cluster with a non-clustered DR server backing it up? Whats the best way to set those 2 pieces up to play music together? Thanks again in advance to all who reply!
Post #968513
Posted Thursday, August 12, 2010 6:43 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, May 29, 2011 9:01 AM
Points: 211, Visits: 4,106
dso808 (8/12/2010)
Hi and thanks so much for your help. Your suggestion sounds like the most feasible solution for our situation. We've also thought of perhaps setting up the DR server to mirror our user databases, recreate all logins, jobs, maintenance plans etc onto the DR server, and then make procedures so that going forward, all changes to our production server (the cluster) are also made to the DR server.

But lesson learned. System database backups from a cluster should only be restored onto that cluster - NOT to another instance. Especially into an instance in a non-clustered environment.

Any one else have input? Anyone else have a cluster with a non-clustered DR server backing it up? Whats the best way to set those 2 pieces up to play music together? Thanks again in advance to all who reply!


you can restore the system databases on other instance, however the productversion(serverproperty('ProductVersion')) of other system should be the same, or otherwise it would not let you restore it.
Post #968625
Posted Friday, August 13, 2010 3:50 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: 2 days ago @ 7:06 AM
Points: 225, Visits: 474
See when you already have your prod server on a cluster and this exercise you're doing for the worst case scenario, then I don't think you need a more spare box sitting idle for this situation to happen... secondly you can restore system db's of a cluster to a non cluster server and to avoid these errors better install the same version of sql server on DR box, with same default setting for data & log files (no need to be identical in terms of hardware but at least the number of drives shud be same in number and in size also if you'r planning to restore all user db's)

this will eliminate all the errors you were facing after restoring master.....

I've one more addition for your DR strategy, if you're data & log drives are on san then in this scenario when your server is down and your SAN is up then you can directly attach those drives to this new DR machine.


Rohit
Post #968761
Posted Friday, August 13, 2010 10:16 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Friday, October 10, 2014 11:06 AM
Points: 1,570, Visits: 680
I just went through an off-site DR recovery Exercise (Scottsdale AZ, in June - no matter how dry it is, 110 is still HOT; and for all you people in AZ, 6% humidity is NOT humid, contrary to what a local weather forecaster stated). This is the document I authored and used as the step-by-step guide, and it worked really well. You may not want all of this, and I removed anything specific to my company. This is for SQL 2008, and is written for a separate SSAS Instance.




1. Install .Net Framework 3.5, SP1
If needed, install .Net Framework 3.5, SP1.

2. Configure SQL Service Account with the ‘Perform Volume Maintenance’ permission (Only do this if your standards require it and / or permissions / standards allow it)
The ‘Perform Volume Maintenance Tasks’ allows SQL Server to allocate Data files (.mdf and .ndf) without zero-filling the file space, this will reduce database restore times by approximately 50%.
To grant ‘Perform Volume Maintenance Tasks’, (this requires Local Administrator rights):
i. On the Start menu, click Run. In the Open box, type secpol.msc on the server. The Security Policy editor opens.
ii. Under Security Settings on the left, go to Local Policies and under that to User Rights Assignment.
iii. Under Policy on the right side, go to "Perform volume maintenance tasks" and double click on it
iv. On the Local Security Setting tab click on the "Add User or Group" button
v. Click the ‘Object Types’ button, and check ‘Groups’ in the Object Types dialog. Click ‘OK’.
vi. In "Select Users, Computers, or Group", "Enter the object names to select" enter the SQL Server service account / service account group in Domain\Account format.
vii. Click [OK].

3. Install SQL Server
Instance Name [Your Server name here]
Components to Install
• RDBMS (SQL Engine)
• SSIS
• SSRS, in Native Mode
Service Accounts – use standard Service Accounts
• SQL Server [Service Account ???]
• SQL Agent [Service Account ???]
• SSRS [Service Account ???]
• Full Text [Service Account ???]
• SSIS [Service Account ???]
• Browser [Service Account ???]

4. Configure SQL Server

5. Install SSAS
Instance Name [Your Server name here]
Components to Install
• SSAS
Service Accounts – use standard Service Account
• SSAS [Service Account ???]

6. Configure SSAS

7. Recreate Users – OLAP
Add following Users to Server Role on SSAS:
• [Domain\User]
• [Domain\User]
(etc)

8. Patch SQL Server
Install SQL Server SP1 – apply to all installed components.

9. Restore master Database - SQL
1. Stop all SQL Server components in SQL Server Configuration Manager, and set everything to Manual Startup.
2. Start SQL Server in single-user mode:
In SQL Server Configuration Manager:
a. In the left pane, select SQL Server Services.
b. In the right pane, right-click SQL Server, and then click Properties.
c. On the Advanced tab, in the Startup Parameters box: insert -m in front of the existing startup options.
d. Click OK.
e. Start SQL Server.
3. Using SQLCmd, restore the master database:
a. Execute RESTORE DATABASE master from <device> WITH REPLACE
4. SQL server should have automatically stopped once the master database was restored, if not Stop SQL Server.

10. Modify the system database locations to match the DR Installation
1. Restart SQL Server with the –T3608 Trace Flag (NoRecovery)
In SQL Server Configuration Manager:
a. In the left pane, select SQL Server Services.
b. In the right pane, right-click SQL Server, and then click Properties.
c. On the Advanced tab, in the Startup Parameters box: insert –T3608 after the –m startup option.
d. Click OK.
e. Start SQL Server.
2. Using SQLCmd, modify the files for msdb, model and TempDB.
At a SQLCmd prompt:
a. Execute SELECT name, physical_name FROM master.sys.master_files WHERE Database_ID < 5
b. For each file listed, execute ALTER DATABASE {db} MODIFY FILE (NAME = {name}, FILENAME = '{filename}') where {db} is the database, {name} is the logical name from the list and {filename} is the path to the installed data folder with the file name from the list.

11. Restore msdb Database - SQL
1. Restore the msdb database:
a. In SQLCmd execute RESTORE DATABASE msdb from <device> WITH REPLACE
2. Restart SQL Server in No Recovery, and multi-user mode:
In SQL Server Configuration Manager:
a. Stop SQL Server.
b. Click SQL Server Services.
c. In the right pane, right-click SQL Server, and then click Properties.
d. On the Advanced tab, in the Startup Parameters box: remove -m from the startup options.
e. Click OK.
f. Start SQL Server.

12. Drop User Databases from restored master DB - SQL
1. Drop existing user databases, including ReportServer databases.
2. For each database:
a. Set the database to OFFLINE
b. DROP the database.

13. Restore User Databases from restored backups from tape - SQL
1. Restore user databases to default locations for SQL
ReportServer databases must be restored to the same name they were backed up from.

14. Restore User Databases - SSAS
1. Restore databases to default locations for all OLAP Server databases in the backups recovered from Tape

15. Recover Reporting Services
In Reporting Services Configuration Manager,
1. Point SSRS to the restored Report server Databases:
a. In the ‘Database’ tab, click the [Change Database] button,
b. Select ‘Choose and Existing Report Server Database’, click [Next],
c. Make sure the local SQL Server is selected, click [Next],
d. Select the restored Report Server database, click [Next],
e. Complete the dialog with [Next] until finished.

2. Restore the .snk encryption key file from the production SSRS Instance:
a. In the ‘Encryption Keys’ tab, select the [Restore] button,
b. Navigate to the File Location of the .snk file restored from tape,
c. Enter the Password, click [OK],




Post #969087
Posted Friday, August 13, 2010 12:15 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, July 22, 2011 2:04 PM
Points: 64, Visits: 164
Thanks Ramji - our cluster does use a SAN so your tip is definately useful!
Post #969171
Posted Friday, August 13, 2010 12:20 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, July 22, 2011 2:04 PM
Points: 64, Visits: 164
Thanks Simon! Wow, this document will definately be a useful template for creating our own DR procedures. Looks great. Thanks again.

Post #969176
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse