July 11, 2013 at 7:06 am
I need to migrate all the servers I support from Windows Server 2008, to 2008 R2 by the end of the year (plenty of time, really.) All the servers are virtuals, and all of them are running SQL 2008 R2. Seeing as they're configured with an OS drive, and multiple data / SQL Server drives, I had a thought on a possible way to migrate quickly.
Of course, this method does have the downside of being one way, with no quick way to go back if it doesn't work...
My thought is, set up a new VM with just an OS drive and the OS. Once this is ready, on the current server, detach all the DBs, and stop the SQL service (the reason for the detach will become apparent.) Have the VMWare admins then remove the data drives from the "old" server, and attach them to the new. Once the drives are attached, delete EVERYTHING except where the DBs / TLogs live, install SQL 2008 R2 as normal and update as needed, then proceed to attach all the DBs I detached.
My thinking (if this idea has merit) is this gives me a few advantages:
1. I don't need to worry about the VMWare / Storage admins complaining about space, I'm just switching already used space from one VM to another...
2. I think this might go a bit quicker than backing up each DB on the old, copying the backup to the new, then restoring.
Of course possible problems:
1. If this doesn't work well, or a DB doesn't come up, my only fall back is a backup of the DB.
2. If it takes longer than expected, I may have users hitting me with "why isn't it done yet, what's taking so long..."
I'm mostly interested in whether people think this would be a way to do this. If you ignore the VM part, it'd be no different than buying a new server, installing the OS, then pulling out the drives from your old server with the DBs on them and installing them in the new...
Of course, a better solution would be if I could get the VMware admin to "clone" the data / log drives and attach the clones to the new VM. But that potentially brings in a fight with the storage guys...
Thanks,
Jason
July 11, 2013 at 9:03 am
Try it and see how it works. I've done similar things myself but you will never know how or if it will work until you try.
The probability of survival is inversely proportional to the angle of arrival.
July 15, 2013 at 3:06 am
Work out the risks of your approach and the risks of other approaches, and discuss these with your manager. Part of your manager's job is to approve the work done by their team and take responsibility if they choose a high-risk approach.
A lower risk alternative to your proposal would be to build new servers, complete with all the disk storage they need. For cutover you have two main choices:
a) You can use SQL replication or mirroring to duplicate data to the new servers, and cut over appilcations to the new servers on a case by case basis. (This has very low risks, as you can revert to the old servers at any time.)
b) You can schedule some downtime, then use backup and restore to transfer the databases to the new server then cut over the applications, then open up user access
Building new servers will take more disk space, which has a cost, and your manager needs to be aware of this. However, it is your manager who should decide on the approach the business should take, not yourself.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply