I have a server whose hard drive is failing and unable to get an image of the hard drive. This particular server is one of the most important on my network as it is my SQL database server and links to multiple other services: Microsoft Team Foundation Server, Microsoft Sharepoint, IBM Tivoli Endpoint Manager (BigFix), among several of my personal developments.
Since I have upgraded my virtual host server I plan on running my new SQL server as a virtual (see: 1, 2, 3) . I’m assigning 4 cores and 3 vhd files running from multiple hard drives within my virtual host server. This should serve my applications well. I’m now left with the problem of migrating my databases from the old failing server to the new one.
The first thing to do is stop all services that rely on the old SQL server.
Stop my custom vGPS website
First up, my custom virtual GPS website… This website provides an easy way to take someone’s public IP address and performs a database lookup, then returns the previously recorded GPS coordinates.
Stop Team Foundation Server
Next up, my Team Foundation Server… here I plan on just shutting down that virtual. During my migration process I plan on changing the DNS name for my old SQL server to point to the new SQL server. Thus when TFS starts back up, it shouldn’t see anything change.
Stop Tivoli Endpoint Manager services
Finally I’ll need to disable my BigFix infrastructure by stopping all of the related services.
I had to stop my BES Client also due to the policies I’ve put into place which monitors for stopped/failed services and restarts them.
While I’ve been working documenting what needs to be stopped, I’ve also been preparing and updating my new virtual SQL server. Windows Updates, attaching to domain, installing SQL, etc…
Visit my “Installing Microsoft SQL Server 2008r2” for details on how to setup your own SQL server.
Now we’re ready to, backup/detach/move/attach our databases.
First let’s backup each of the databases that will be migrated over:
Open up SQL Mgmt Studio
Open up the localhost->Databases and right click on each database->Tasks->Back Up. The default location should be fine unless your shy on space. If so, remove the destination at the bottom and redirect to a different location.
Repeat until you have all of the desired databases backed up and safe.
Since I went with the defaults, all of my database backups show up in “C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup”. I will leave them there for now and utilize them if something goes wrong later on.
Next we’ll need to Detach these databases from the old SQL Server.
The database files will remain where they were. In my case I had them configured to sit in the default directory:
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
This process will detach the database from this instance of SQL server and locks the two related files: [database name].mdf and [database name]_log.LDF
I will repeat the detaching process until I get all 10 databases. 1 for my custom vGPS application, 4 related to BigFix, and the 5 related to TFS.
I now have 20 files to be moved over to the new SQL server. I’ll do this using robocopy. See my Robocopy how-to in a different article.
robocopy ./ "\\vsql\e$\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA" -z –e
After the move, I wanted to position the transaction log files in a different “drive” than the database files… so I selected all of the _log files and moved them to a separate VHD which sits on a different physical RAID array than the OS and Data VHD’s. This is due to performance reasons related to BigFix.
Nearly an hour and a half later…Attaching Databases
I encountered a SQL error 5123 while selecting my mdf file. This is because the DATA directory is protected. I solved that by simply exploring to that directory and when asked for “admin” access to it, clicked yes. Then choosing OK to the above dialog went as expected…
Since my Data and Log files reside on two different VHD drives, I needed to specify the path to each file separately. The previous file selection automatically chose the correct Data file, and since my path matched between the Data VHD and the Logs VHD, I only needed to change the Drive letter.
Next, repeat that for each of the databases that are being moved over…
I opted not to perform this and simply recreate the couple of logins I needed. Since only 3 services are currently using the SQL Server, recreating them was quick and extremely easy.
I also opted to change the DNS alias the three services were connecting to. On my old server, both BigFix and SQL were running on the same box. I decided to separate them into two separate virtuals. vSQL will host my SQL server and allow all three services to connect into it. vBigFix81 will serve as my BigFix server running version 8.1. If I want to upgrade to 8.2 or beyond, I’ll simply create upgrade vBigFix81 to get upgrade documentation, then create a brand new vBigFix82 virtual, install 8.2 and change the BigFix DNS alias.
Now onto restoring each of my services…
Restoring Team Foundation Server
It made logical sense to restore this service first. My vGPS service will need alias’s updated in code which is stored on my TFS. So…
Turns out this is extremely easy. I only needed to update the web.config file under “C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services” with the new DNS alias for my SQL server. I found information on this from http://msdn.microsoft.com/en-us/library/ms404869(v=vs.80).aspx which pointed me to the Web.config for other reasons. While there I remember for many of my apps, I have to configure the database connection within this file. And done!
I was able to do that LIVE and the connection automatically repaired the db logins needed and established connections to the newly attached databases.
Restoring vGPS my Custom App
This is extremely easy as it was a simple matter of checking out my code from the TFS server, do a crtl-h to replace the alias, save and publish. Testing showed my DB user account wasn’t configured right, so I made the appropriate adjustments and all done. App works perfectly with the new SQL DNS alias.
This one I take my time on because I really enjoy installing, customizing, and playing around with my companies program.
Now that my three services have been restored and validated… the upgrade of my Microsoft SQL 2008r2 SP1 is now complete!
Please leave comments and questions below!