June 20, 2017 at 12:08 pm
Hello, we are migrating to a cloud environment and I am curious if it is possible to clone a SQL Server? We will be standing up several instances and really really don't want to stand each one up from scratch. I know SQL wouldn't be happy in regards to server name/IP etc.. but assuming all the hard drive letters are the same and the architecture is the same... is it possible to clone?
I was assuming there would be some registry editing or modifying of the system databases but didn't know if anyone had an established process for this I could piggy back on? I'm not even sure where to start with what would need to be modified in order for SQL Server to be happy after its cloned.
We would be cloning stand alone instances of SQL Enterprise edition with no HA configured or anything. We do have server audits and specifications set up though.
June 21, 2017 at 5:29 am
You're not saying which cloud environment you're looking at. Let's say it's Azure. Then, yes, there is absolutely a way to "clone" the environment using ARM Templates. To learn about this, start with the Quick Start Templates and then you can use these as the basis for building your own.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 21, 2017 at 7:30 am
Another option might be to investigate the Start-SqlMigration function in the powershell DBATools package.
Thomas Rushton
blog: https://thelonedba.wordpress.com
June 22, 2017 at 3:52 pm
amy26 - Tuesday, June 20, 2017 12:08 PMHello, we are migrating to a cloud environment and I am curious if it is possible to clone a SQL Server? We will be standing up several instances and really really don't want to stand each one up from scratch. I know SQL wouldn't be happy in regards to server name/IP etc.. but assuming all the hard drive letters are the same and the architecture is the same... is it possible to clone?I was assuming there would be some registry editing or modifying of the system databases but didn't know if anyone had an established process for this I could piggy back on? I'm not even sure where to start with what would need to be modified in order for SQL Server to be happy after its cloned.
We would be cloning stand alone instances of SQL Enterprise edition with no HA configured or anything. We do have server audits and specifications set up though.
Both Azure and AWS support a P2V type migration of a server from on-premise to the cloud environment. I have clients that have done SQL Server on-premise to an AWS EC2 instance with no downtime. We had monitoring watching the server and literally we never got paged on that SQL Server went offline.
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
June 22, 2017 at 5:54 pm
Hi! Sorry I'm late replying.....
We are going to AWS but I'm not trying to do the cloning to "migrate" to AWS but just take AMI copies of the AWS EC2 servers. We have to apply STIGs and will have to be doing duplicative instances for HA (they are cold sites though)... so I don't want to stand up every environment each time from scratch.
We had looked at sysprep for SQL Server but it only allows you to snapshot an unfinished configuration of sql server... so, was just trying to figure out if we did take an AMI of the server and clone it (snapshot it), what it would take to make my SQL Server on the cloned machine happy.
Thanks!
June 22, 2017 at 5:58 pm
ThomasRushton - Wednesday, June 21, 2017 7:30 AMAnother option might be to investigate the Start-SqlMigration function in the powershell DBATools package.
Woah this looks pretty neat! I watched the video of the migration.... did it do the master and system databases as well?!? If it did then I'm sold. 😀
June 22, 2017 at 10:05 pm
You can clone an EC2 instance by making an AMI image of it. Then create another one based off it. There are some things that are not copied in that AMI but AWS documentation covers it.
To make it happy will be just like you cloned a VM in your domain from VMware. You bring it up off the domain network so it doesn't conflict and get the computer and IP adjusted. Then you will also need to update the network configuration for SQL Server to update the IPs it listens on.
Regarding the start migration command, not it does not physically copy the system databases, although there is work on building that functionality to at some point. However, you don't really need the system databases if all the dependent objects and configurations for the instance are copied.
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
June 23, 2017 at 6:09 am
Ok, so if we do the AMI clone - then everything comes with SQL including the system databases.and all I have to do is change the servernames/IPs and the TCP/IP settings in the configuration manager?
Which one would be a better practice.... doing the AMI clone or doing the SQLMigrate with the powershell?
June 23, 2017 at 6:25 am
amy26 - Friday, June 23, 2017 6:09 AMOk, so if we do the AMI clone - then everything comes with SQL including the system databases.and all I have to do is change the servernames/IPs and the TCP/IP settings in the configuration manager?Which one would be a better practice.... doing the AMI clone or doing the SQLMigrate with the powershell?
Why not both. You can automate the AMI calls through PowerShell and add additional steps to cover short comings. Same approach I'd take doing this through Azure.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 23, 2017 at 6:38 am
amy26 - Friday, June 23, 2017 6:09 AMOk, so if we do the AMI clone - then everything comes with SQL including the system databases.and all I have to do is change the servernames/IPs and the TCP/IP settings in the configuration manager?Which one would be a better practice.... doing the AMI clone or doing the SQLMigrate with the powershell?
When you create an AMI of the server it will grab only the system drive. You would need to create a snapshot of any additional volumes you have on the server and then restore those as new volumes and attach to your new EC2 instance, then remap the drives and such. It has been a while since I have done this method in my lab on AWS.
It is not a better practice really to go either way, it is more of just preference and time. You can automate it in AWS but not necessarily through PowerShell unless Lambda functions support that language now (have not played with them any).
Utilizing dbatools and PowerShell would make it more automated, and mostly manageable for changes. If you are using AMIs you may have some parts of the process that can't be automated (I've never tried to automate it fully) and look at what you have to do when a configuration changes on your primary ("original") server. You can automate the creation of AMIs using Lambda functions but compare that to just running dbatools in PowerShell to update your downstream servers.
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
June 23, 2017 at 7:03 am
Well let me also put it another way... we are all sort of noobs at this AWS stuff, so I need to do things the simplest and less complicated way too! 🙂
That's a good point about the changes to the environments... I would think the dbatools route would be better cause I could migrate things super fast.
Ok, maybe I'm confused about what the AMI stuff is... its not like Ghost where it just snapshots the entire server and makes a copy of it? Do you still have to install SQL Server and all the software when you do an AMI?
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply