Migrate database from Hyper-V to VMware
-
@nerdydad said in Migrate database from Hyper-V to VMware:
@scottalanmiller said in Migrate database from Hyper-V to VMware:
Why not back up through normal MS SQL means and restore using its own tools?
This will probably be our best avenue.
@dustinb3403 said in Migrate database from Hyper-V to VMware:
I'm guessing he is wanting to migrate the entire VM rather than just the database, hence the question.
But I'd agree using the MS SQL backup and restore approach would likely be best.
The next option down from that would be to export the VM and import it into VMWare, but you'll likely need to convert the disks to whatever VMWare supports.
We're actually going to build new 2016 servers. So, we're just going to migrate the data.
The biggest problem of all of this is going to be finding the downtime to migrate all of the data from the old system to the new system. We're looking at 1 TB of data including the database and all of the transaction logs.
Can't you sync the databases?
-
@black3dynamite said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
@scottalanmiller said in Migrate database from Hyper-V to VMware:
Why not back up through normal MS SQL means and restore using its own tools?
This will probably be our best avenue.
@dustinb3403 said in Migrate database from Hyper-V to VMware:
I'm guessing he is wanting to migrate the entire VM rather than just the database, hence the question.
But I'd agree using the MS SQL backup and restore approach would likely be best.
The next option down from that would be to export the VM and import it into VMWare, but you'll likely need to convert the disks to whatever VMWare supports.
We're actually going to build new 2016 servers. So, we're just going to migrate the data.
The biggest problem of all of this is going to be finding the downtime to migrate all of the data from the old system to the new system. We're looking at 1 TB of data including the database and all of the transaction logs.
Can't you sync the databases?
Something else to look into. I've considered replicating all of the data over from old to new and then, over a weekend, failing over to the new and reversing the replication.
-
Make sure if you do backup the SQL databases and restore that the security gets backed up and restored as well. I've seen instances where a database was restored along with security permissions on the database, but there were no SQL logins created on the target instance to map to the restored database permissions.
-
@networknerd Along this line I jsut dealt with a backup and restore last week where the SQL log ins were created after the database was reqtored and the SQL login in the database had to be deleted and then permisisons reapplied to the database form the mian login securty settings for the SQL user.
-
@nerdydad One does not simply replicate data to disparate systems with Veeam.
While it may be entirely possible, I would never try it.
Use SQL's replication features.
-
@nerdydad said in Migrate database from Hyper-V to VMware:
We're looking at 1 TB of data including the database and all of the transaction logs.
1TB of data or 1TB of transaction logs? Your transaction logs should be tiny if you schedule this after a backup.
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
We're looking at 1 TB of data including the database and all of the transaction logs.
1TB of data or 1TB of transaction logs? Your transaction logs should be tiny if you schedule this after a backup.
1 TB of data. A little bit more than 500 GB of transaction logs on the database.
-
@nerdydad said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
We're looking at 1 TB of data including the database and all of the transaction logs.
1TB of data or 1TB of transaction logs? Your transaction logs should be tiny if you schedule this after a backup.
1 TB of data. A little bit more than 500 GB of transaction logs on the database.
So that is 1.5 TB to transfer. also WTF on 500 GB of transaction logs. What kinds of rollbacks are you trying to be able to handle.
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
We're looking at 1 TB of data including the database and all of the transaction logs.
1TB of data or 1TB of transaction logs? Your transaction logs should be tiny if you schedule this after a backup.
1 TB of data. A little bit more than 500 GB of transaction logs on the database.
So that is 1.5 TB to transfer. also WTF on 500 GB of transaction logs. What kinds of rollbacks are you trying to be able to handle.
They are merged into the database nightly. This systems manages everything between our accounting, to customer service, to raw materials, to boxing and shipping.
-
@nerdydad said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@nerdydad said in Migrate database from Hyper-V to VMware:
We're looking at 1 TB of data including the database and all of the transaction logs.
1TB of data or 1TB of transaction logs? Your transaction logs should be tiny if you schedule this after a backup.
1 TB of data. A little bit more than 500 GB of transaction logs on the database.
So that is 1.5 TB to transfer. also WTF on 500 GB of transaction logs. What kinds of rollbacks are you trying to be able to handle.
They are merged into the database nightly. This systems manages everything between our accounting, to customer service, to raw materials, to boxing and shipping.
So if you schedule your downtime for post merge, then you only have 1TB to move.
-
As for how to do this.
I would simply schedule extended downtime after backups run, shut down the database access and migrate the backup file.
Obviously, this would be done after simply spinning up the new system with a backup file and confirming any other steps that you need to take.
You have no HA now, why try to implement some half baked HA just to migrate?
-
Could you restore the backup on the new server whilst the old server is still live and after it is restored on the new server shut down live and do a differential backup and then restore the differential backup on the new server?
That would minimise downtime as the differential backup will be much smaller than the full 1TB backup. Although with 500gb of transaction logs, maybe not so much.
-
Last year I moved a Vm from HyperV to Vmware, It had Sql Server with a database of 300Gb, for Ms Ax.
I just stopped all Ms Sql Server services and migrated using VMware Standalone Converter.
After the migration I started all Sql services again and everything worked.
-
@iroal said in Migrate database from Hyper-V to VMware:
Last year I moved a Vm from HyperV to Vmware, It had Sql Server with a database of 300Gb, for Ms Ax.
I just stopped all Ms Sql Server services and migrated using VMware Standalone Converter.
After the migration I started all Sql services again and everything worked.
This is just a normal V2V conversion. Which many of us have already discussed, but it adds to what would need to be converted.
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
Yes it's simpler, just convert the entire block device, but it adds a some risk that there could be a broken system within whatever gets converted and started up.
-
Not to mention the amount of downtime required to convert the working system to the VMWare standard. Which may not be acceptable for the business.
-
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
-
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Not to mention the amount of downtime required to convert the working system to the VMWare standard. Which may not be acceptable for the business.
This downtime will, likely, not be particularly different than the offline time to backup, transfer, and restore a 1TB database.
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
Yeah while true, anyone who is setting up this database system should be able to account for these issues as they are a part of the "installation process".
Rather than some random bug or crash due to a registry entry that decided to go haywire in the middle of a production day.
-
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Not to mention the amount of downtime required to convert the working system to the VMWare standard. Which may not be acceptable for the business.
This downtime will, likely, not be particularly different than the offline time to backup, transfer, and restore a 1TB database.
I was simply accounting for the OS size as an additional amount rather than creating a new system with a SQL system ready to receive a database.
-
@dustinb3403 said in Migrate database from Hyper-V to VMware:
@jaredbusch said in Migrate database from Hyper-V to VMware:
@dustinb3403 said in Migrate database from Hyper-V to VMware:
Instead, standing up a new installation with a fresh MS SQL waiting for a database and attaching the backup to the database means you don't have to worry about any wonkiness that might occur due to the conversion from Hyper-V to VMWare.
This has issues of its own to deal with. Because there are a lot of ancillary bits to most MS SQL (or any SQL really) deployments that are not part of a database backup.
Yeah while true, anyone who is setting up this database system should be able to account for these issues as they are a part of the "installation process".
Actually, no. Because these types of things are usually, setup once 5 years ago with vendor support, type scenarios.
Rather than some random bug or crash due to a registry entry that decided to go haywire in the middle of a production day.
It is a V2V, nothing is happening in production.
