Friday, January 10, 2020

Cloning SQL Servers


It is common for our customers to clone virtual  servers.  Sometimes they even clone SQL servers.  We even tell them to do this sometimes, such as when we want to create an identical test environment.

It is a huge time saver, but when cloning a SQL server, there are a few additional things we need to watch out for.  If the customer IT person is not a DBA, they will most likely have no clue to watch out for these things.

*** If the SQL server they are cloning has drive mappings or any type of alias to the storage location where SQL data, log, or backup files reside, these may need to be re-mapped on the clone.  Before using a cloned SQL server, verify the drives you see are not really the production drives. 

The easiest way to check is to launch the cloned server and save an empty text file to each storage location, then launch the production server and see if you can see the files.  If you can, STOP!  It means the new SQL server may try to modify production data.  The SQL services on the cloned server should be stopped immediately until the problem can be addressed.  Each server should have completely physically isolated storage.

*** If the SQL server has maintenance plans:  Maintenance plans create jobs and have a hardcoded connection string to the jobs they create.  On the cloned server, these connection strings will point to the production server.  This may cause SQL jobs to fire twice.  This will be noticeable for backup plans because there will be 2 nighty backup files generated, or job failures due to conflicts.  This will also degrade performance during the day on the production server. 

The correct way to prevent this starts BEFORE the cloning.  Record the steps in the maintenance plans on the production server, then disable all the plans and jobs on the production server before cloning it.  Re-enable them after cloning is complete.  Then on the clone server, delete the maintenance plans and re-create them.  Check all the other jobs to make sure their connection (bottom left of the job properties window) is correct before re-enabling them.


SQL 2022 TSQL snapshot backups!

  SQL 2022 now actually supports snapshot backups!  More specifically, T-SQL snapshot backups. Of course this is hardware-dependent. Here ...