In order to help prioritize our development, please let us know if anything on this page is a barrier to using SQL Clone.

Current known limitations of SQL Clone

• The source of an image cannot:
  • Be a SQL Server database snapshot.
  • Be a database which is standby or in recovery.
  • Be a live database currently part of a failover cluster.
    • Images can be created using backups of such a database but the backups will have to be restored to a SQL Server instance that is not part of a failover cluster.
    • Images can be created from availability groups.
  • Be a live database stored on a partition that is larger than 64 TB.
  • Be a live database whose data files (usually mdf/ldf/ndf) are stored on a different machine to its instance.

• Clones cannot be created into failover clusters or availability groups, or inside containers.

• Clones cannot be created on a SQL Server with an earlier version than where the image was created (later version is fine).

• CLR assemblies are not ported to other machines by SQL Clone. These may have to be registered in a post-clone step if they are required.

• The size of database within an image or clone cannot be larger than 64 TB.

Known issues

• There is a compatibility problem between SQL Clone and SQL Data Masker, which generates Executable not signed error when attempting to modify an Image with Data Masker as part of the image creation process:
  • If using SQL Clone V5.4.21 or earlier, please ensure that you have SQL Data Masker V7.1.40 or earlier installed.
  • If using SQL Clone V5.5.0 or later, please ensure that you have SQL Data Masker V7.1.41 or later installed. 
• Progress indications for creating images from Redgate SQL Backup files may pause during restoration of the log files.
• Progress indications for creating images from very large live databases are inaccurate.
• When creating an image from a multi-database backup, only the first database within the backup will be imaged.

Untested scenarios

• Running under a group managed service account.