Creating a database copy with SQL Clone is a two stage process. First you have to create the data image which takes as long as a backup or restore depending on the database size and then you can create the clones. When a clone is created, it is essentially just a Virtual Hard Disk (VHD) mount point that references the data image, plus a differencing disk. So even for database up to 2TB in size, clones will take just seconds to create.

With PowerShell, the creation of data images and clones to be automated so that, for instance, the process can be scheduled for night time maintenance windows. Creating clones will save you hours of time and give you and your team on demand access to refreshed database copies.

The size of a clone will typically start at around 40MB. This is because a clone is simply creating a VHD mount point that can reference the data image (full copy of the database) plus a local differencing disk. Of course if you make changes to the clone then the size will change. SQL Server thinks clones are full sized database copies, and does not know that a clone is just referencing the data held in the data image. This removes the need to spend hours juggling disk space and allows teams to work in isolation on their own workstations to develop, test and fix code.

The SQL Clone Server is the single source of truth for the creation, management and removal of data images and clones. The architecture of SQL Clone means you have a central view of what clones have been created, how much disk space they are using, when they were created, and by who. The masking or removal of sensitive data can be applied to a clone, and new data images can be taken to capture these changes allowing you to keep data secure. Inbuilt access permissions allows you to control who in the team can create and manage clones using the SQL Clone Server.

So whether you allow your team to self-serve clones and want transparency over what has been created, or you just want a central place to create and manage clones yourself, SQL Clone makes provisioning simple.

SQL Clone removes some of the key blockers teams face when working with databases, disk space, and the time it takes to create a database copy. Creating clones takes seconds and depending on the permissions you set, teams can self-serve meaning fewer provisioning requests and instant access to refreshed database copies.

Teams can test more accurately using a realistic copy of production, or use cloned databases to create test scenarios without using terabytes of disk space. And because clones are so small, individuals can work locally in isolation, experiment, and make mistakes without impacting the rest of the team.