June 24, 2013 at 2:42 am
what are the high level steps to move a server from one datacenter to another datacenter ?
Thanks
June 24, 2013 at 11:03 pm
High level (assuming local storage and an allotted outage window):
1. Determine what applications (or other dependencies) connect to the server
2. Determine if the server is used for anything other than hosting databases
3. Plan an outage window with adequate time to do the following...
4. Stop any applications making connections to the databases
5. Take full (and trans log backups if in full recovery) backups of all databases including master, model, and msdb to reliable remote storage
6. Backup any other important files on the server (don't forget SSRS files, SSIS packages, etc)
7. Stop database (and any other necessary) services
8. Power down server
9. Move and re-rack/cable server at new data center
10. Power on server
11. Start database services
12. Start applications and ensure they can connect to the databases
13. Verify all jobs/scheduled backups are working correctly
June 24, 2013 at 11:56 pm
Turn off power
Wait for screams
Turn on power
Organise outage window with screamers
Move server
😀
June 24, 2013 at 11:59 pm
thanks..
June 26, 2013 at 6:31 am
The high-risk approach is to shut down the servers, move them to the new DC, then start them up. It can be done, and I know of organisations that have been successful in doing this, but they knew it was high risk. I have also known of a truck crashing with the result that a lot of kit was too bent to be used.
If anything breaks you could have a service outage until you buy a new server and get everything installed and tested (maybe a week or two or more).
The low risk approach is to build a new environment in the new data centre, while you keep the old environment running. Seriously consider replication from old to new so that you have the same data in both locations. This allows you to do a phased cutover, with very quick fall-back to your old environment if anything breaks.
When we moved from hosted to AWS, we implemented SQL P2P replication, so we had the same daat in the two old data centres and the two new AWS Availability Zones. We then used Route53 to cut over traffic in 5% intervals, so we could be sure that things were behaving before we committed to AWS. This approach had some complexity (P2P across 4 locations), but the ability to switch workload around in a second or two very significantly reduced risk.
You should look at what options are available to you, then work out the risks of each approach and present this to your management. They will sign off on what they consider best for the business, and it is then down to you to implement it. If they go for a high risk approach, make sure your CV is up to date before you start the move - if the company folds because a truck crashes, at least your personal DR plan will be in place.
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 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply