Duplicate an 8TB SQL Database from Prod to Dev in less than 60 seconds – Part 2

This is part 2 of the series. If you haven’t read part 1 yet, you should. Go here.

Welcome back. To recap, we’ve successfully snapped our prod (source) database and replicated it to dev (target). Now here’s where the real magic happens. With the help of some PowerShell, we can replace (yes, replace) the active dev database with prod.

I should take a moment to remind you of a very important consideration. Due to the fact that this is a SAN level process, the entire windows drive gets replaced with production’s drives. Don’t proceed if your dev server has other databases running on these drive letters. You’ll lose your databases!


First, let’s make our lives a bit easier and grab some data that we’re going to need for the script. Here’s the list of variables you’re going to need:

  • Target Server FQDN (I shouldn’t need to tell you how to find this)
  • Target Server Volume Device IDs
  • Target SAN FQDN (I shouldn’t need to tell you how to find this)
  • Target SAN Volume Names
  • Source SAN Volume Names
  • Protection Group Name
  • Database Name(s) (I shouldn’t need to tell you how to find this)

Determining Target Server Volume IDs

  1. Run the Windows Disk Management utility (diskmgmt.msc)
  2. Take note of the “Disk #” for the drives you are going to be restoring.

Determining Source SAN Volume Names

  1. Login to the Source SAN Management UI
  2. Go to the “Storage” pane, then click the “Volumes” heading.
  3. Take note of the volume names you are going to be using as the source for the restore.

Determining Target SAN Volume Names

  1. Login to the Target SAN Management UI
  2. Go to the “Storage” pane, then click the “Volumes” heading.
  3. Take note of the volume names you are going to be restoring.

Determining the Protection Group Name

  1. Login to the Target SAN Management UI
  2. Go to the “Protection” pane, then click the “Protection Groups” heading.
  3. Take note of the name under “Target Protection Groups”

Scripting the restore

Now that we have all the information we need, it’s time to build the script and restore your databases!

We’re going to be using SQL scripts provided by Pure Storage’s Collab GitHub. Specifically, Refresh-Dev-ProtectionGroups-vVol-v3. Don’t worry about the vVol part, this script works for non-vVols too.

  1. Download the PowerShell script.
  2. Update all the variables with the data you gathered above.
  3. Run the script with a user that has administrative rights to the target server and the “Storage Admin” role on the target SAN.

What is happening? How can this be so fast?

Let’s first start with the fact that the restore process isn’t actually moving any data. Because you’re already doing snapshots of the source, and replicating them to the target, the slowest part of this process (migrating data) is already happening behind the scenes.

What does the script actually do?

  1. The database is set offline in SQL Server
  2. The volumes (drives) are set offline in Windows
  3. The storage array replaces the volumes in the SAN with a clone of the snapshot
  4. The volumes are then brought back online in Windows
  5. The database is brought back online in SQL Server

This method means Windows and SQL Server (on both the source and target) have no idea anything happened. The database is just replaced.

In my environment, this restore process consistently takes 51-53 seconds. SECONDS! To restore an 8TB database.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *