Stay organized with collections
Save and categorize content based on your preferences.
You can clone (copy) a backup of a SQL Server database, instance or AG image to
any SQL Server host known by your backup/recovery appliance.
The cloning process varies slightly depending on whether you are cloning a
single database image such as a member of an Always on Availability Group (AG)
or multiple images in a SQL instance.
Use a clone operation:
If you have copies of multiple SQL Server databases on a single volume,
to avoid unintentional data loss as the contents of the entire volume
get overwritten during restore of the volume.
If the original database has been removed because of corruption,
or if the old database server is being replaced with a new server.
You can use a clone to effective restore SQL Server databases onto any
host, unlike a restore which can only be run to the source host.
You can use a clone to create an independent copy of SQL Server databases
for test and development where all changes will remain on the users copy
and not get written back to the snapshot pool.
Clones can be used to recover databases to a new location, a new filename,
or both. Clones are created when a source database has become corrupt, or
requires root cause analysis. The clone performs a full restore with optional
point in time recovery to the same host (new database name or filename), or
alternative hosts running the same version or higher. The use cases for clones
include performance testing, long term development and testing, reporting, and
even cloning databases from staging environments into existing production
instances.
To clone a SQL database to a host:
From the Backup and DR Service management console, open the
App Manager to the Applications list.
Right-click the application with the image that you want to clone,
then choose Access. The Access page opens listing backup images in
the Timeline ramp view.
Select an image and then select Clone from the list of access operations.
The Clone page opens.
Select a target from the Target drop-down list.
Optionally, enter a label for the clone job in the Label field.
Under Application Options, select one or more databases to clone.
Unlike the Mount operation, no new Consistency Group is created when
multiple databases are cloned.
If the source application is protected by a snapshot policy that has
enabled database log backups, and logs are available with the image,
you can use them to roll forward to a specific point in time by changing
these options in the Roll Forward Time section:
The date field contains all possible dates that the database can be
rolled forward to, with the application of database transaction logs.
Select the date the database needs to be rolled forward to.
The time field contains a slider showing all possible times on the
selected date that the database can be rolled forward to. If you select
the latest possible date and then move the slider to the right most
position, the job will apply to all available logs. If you select
the earliest possible date and move the slider to the left most position,
the job will apply no logs.
You can specify to roll forward using either User Time or Host Time.
User Time is relative to the local time of the current user. Host time is
relative to the system that hosts the data to be cloned.
In SQL Server Instance Name, select a target SQL Server instance to manage
the new database.
If you are cloning a single database, enter the name for the new database,
avoiding names of existing databases in the selected target server and
instance.
If you are cloning multiple SQL databases you can supply a name for each
database. Under Advanced Options you can also append a suffix or a
prefix, or both to every cloned database's name.
Enable the Rename Files to Match New Database option if you want to
rename the database files to match the new database names.
In the Advanced Options section, enter information for the additional
fields required.
Property
Description
Recover Database After Restore
If Recover Database After Restore is not enabled, the SQL
Server database is left in a state where logs can be rolled forward. When it is
enabled, the SQL Server database is brought online and logs cannot be rolled
forward beyond the time specified in the mount.
Recover User Logins
This applies only if Backup SQL Server User Logins in
the Policy Settings or Policy Settings Overrides is set to Yes (this
is not the default). If that is set to Yes, all user logins backed up
from the source instance are restored into the target instance. Domain
accounts only restore if the target SQL Server is in the same domain
or forest as the source and if any required trust relationships are in
place.
User Name/Password
User credentials for database provisioning.
The User Name is only required when the account
running the Backup and DR agent (typically "Local System")
does not have privileges to apply transaction logs, or to detach a database
(which is typically required during a subsequent unmount).
Overwrite Existing Database
Overwrites the original database.
In the File Locations section, specify whether you want to copy the
database files to the same path as the source server, or to a new location.
There are three options:
Copy files to the same drive or path as they were on the source server
(default option).
Choose new file locations at the volume level.
Choose new file locations at the file level.
If you select the second option (new file option at the volume level),
you will see a table with the source volume and target volume drop-down.
In Target Volume, select a target volumes from the drop-down list of all
discovered file system applications. If needed, you can also type the
volume, for example: M:\, or L:\Logs\Log1.
If you select the third option (new file locations at the file level),
a table with three columns appears: File, Source Location, and
Target Location. In Target Location, enter the new file location as needed.
Click Submit.
A job is submitted to clone the image to the selected host. You can verify
that the clone operation is successful by viewing the job status in the
Monitor.
The Backup and DR Microsoft SQL Server DBA guide
This page is one in a series of pages specific to protecting and recovering
Microsoft SQL Server databases with Backup and DR.
You can find additional information at:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[[["\u003cp\u003eCloning allows copying a SQL Server database, instance, or AG image to any SQL Server host known by the backup/recovery appliance.\u003c/p\u003e\n"],["\u003cp\u003eCloning is useful for avoiding data loss when multiple databases reside on a single volume, or when the original database is corrupt or the server is being replaced.\u003c/p\u003e\n"],["\u003cp\u003eClones enable the restoration of SQL Server databases to any host, unlike traditional restores which are limited to the source host.\u003c/p\u003e\n"],["\u003cp\u003eClones create independent copies for testing and development, ensuring changes don't affect the original data, and they can recover databases to new locations or filenames.\u003c/p\u003e\n"],["\u003cp\u003eThe cloning process involves selecting a source image, a target host, and specifying details like database names, file locations, and options for point-in-time recovery using transaction logs.\u003c/p\u003e\n"]]],[],null,["# Clone Microsoft SQL Server Databases\n\nYou can clone (copy) a backup of a SQL Server database, instance or AG image to\nany SQL Server host known by your backup/recovery appliance.\n\nThe cloning process varies slightly depending on whether you are cloning a\nsingle database image such as a member of an Always on Availability Group (AG)\nor multiple images in a SQL instance.\n\nUse a clone operation:\n\n- If you have copies of multiple SQL Server databases on a single volume,\n to avoid unintentional data loss as the contents of the entire volume\n get overwritten during restore of the volume.\n\n- If the original database has been removed because of corruption,\n or if the old database server is being replaced with a new server.\n\n- You can use a clone to effective restore SQL Server databases onto any\n host, unlike a restore which can only be run to the source host.\n\n- You can use a clone to create an independent copy of SQL Server databases\n for test and development where all changes will remain on the users copy\n and not get written back to the snapshot pool.\n\n- Clones can be used to recover databases to a new location, a new filename,\n or both. Clones are created when a source database has become corrupt, or\n requires root cause analysis. The clone performs a full restore with optional\n point in time recovery to the same host (new database name or filename), or\n alternative hosts running the same version or higher. The use cases for clones\n include performance testing, long term development and testing, reporting, and\n even cloning databases from staging environments into existing production\n instances.\n\nTo clone a SQL database to a host:\n\n1. From the Backup and DR Service management console, open the\n **App Manager** to the **Applications** list.\n\n2. Right-click the application with the image that you want to clone,\n then choose **Access** . The **Access** page opens listing backup images in\n the Timeline ramp view.\n\n3. Select an image and then select **Clone** from the list of access operations.\n The Clone page opens.\n\n4. Select a target from the **Target** drop-down list.\n\n5. Optionally, enter a label for the clone job in the **Label** field.\n\n6. Under **Application Options**, select one or more databases to clone.\n Unlike the Mount operation, no new Consistency Group is created when\n multiple databases are cloned.\n\n7. If the source application is protected by a snapshot policy that has\n enabled database log backups, and logs are available with the image,\n you can use them to roll forward to a specific point in time by changing\n these options in the **Roll Forward Time** section:\n\n - The date field contains all possible dates that the database can be rolled forward to, with the application of database transaction logs. Select the date the database needs to be rolled forward to.\n - The time field contains a slider showing all possible times on the selected date that the database can be rolled forward to. If you select the latest possible date and then move the slider to the right most position, the job will apply to all available logs. If you select the earliest possible date and move the slider to the left most position, the job will apply no logs.\n - You can specify to roll forward using either **User Time** or **Host Time**. User Time is relative to the local time of the current user. Host time is relative to the system that hosts the data to be cloned.\n\n | **Note:** When performing a clone from OnVault, a roll-forward range is displayed only when logs are available on the local appliance. This includes the scenario where an OnVault import was performed on the same appliance used as a target for StreamSnap replication with log replication enabled.\n8. In SQL Server Instance Name, select a target SQL Server instance to manage\n the new database.\n\n9. If you are cloning a single database, enter the name for the new database,\n avoiding names of existing databases in the selected target server and\n instance.\n\n If you are cloning multiple SQL databases you can supply a name for each\n database. Under **Advanced Options** you can also append a suffix or a\n prefix, or both to every cloned database's name.\n10. Enable the **Rename Files to Match New Database** option if you want to\n rename the database files to match the new database names.\n\n11. In the **Advanced Options** section, enter information for the additional\n fields required.\n\n \u003cbr /\u003e\n\n12. In the File Locations section, specify whether you want to copy the\n database files to the same path as the source server, or to a new location.\n There are three options:\n\n - Copy files to the same drive or path as they were on the source server\n (default option).\n\n - Choose new file locations at the volume level.\n\n - Choose new file locations at the file level.\n\n If you select the second option (new file option at the volume level),\n you will see a table with the source volume and target volume drop-down.\n\n In Target Volume, select a target volumes from the drop-down list of all\n discovered file system applications. If needed, you can also type the\n volume, for example: M:\\\\, or L:\\\\Logs\\\\Log1.\n\n If you select the third option (new file locations at the file level),\n a table with three columns appears: File, Source Location, and\n Target Location. In Target Location, enter the new file location as needed.\n13. Click **Submit**.\n A job is submitted to clone the image to the selected host. You can verify\n that the clone operation is successful by viewing the job status in the\n Monitor.\n\nThe Backup and DR Microsoft SQL Server DBA guide\n------------------------------------------------\n\nThis page is one in a series of pages specific to protecting and recovering\nMicrosoft SQL Server databases with Backup and DR.\nYou can find additional information at:\n\n- [Backup and DR for Microsoft SQL Server Databases](/backup-disaster-recovery/docs/concepts/backupdr-for-sql-server)\n- [Prepare SQL Server databases for Backup and DR Service](/backup-disaster-recovery/docs/configuration/prepare-sql-server)\n- [Add a SQL Server database host and discover databases](/backup-disaster-recovery/docs/configuration/discover-sql-server)\n- [Configure backup plans for Microsoft SQL Server instances and databases](/backup-disaster-recovery/docs/backup/back-up-sql-server)\n- [Application details and settings for Microsoft SQL Server instances and databases](/backup-disaster-recovery/docs/backup/app-details-settings-sql-server)\n- [Mount a SQL Server database](/backup-disaster-recovery/docs/access-data/mount-sql-server)\n- [Mount databases into SQL Always On Availability Groups](/backup-disaster-recovery/docs/access-data/mount-sql-server-aag)\n- [Manage an active mount](/backup-disaster-recovery/docs/access-data/manage-active-mounts)\n- [Migrate a SQL Server database](/backup-disaster-recovery/docs/access-data/mount-and-migrate-sql-server-2)\n- [Clone SQL Server databases](/backup-disaster-recovery/docs/access-data/clone-sql-server)\n- [Recover SQL Server backups](/backup-disaster-recovery/docs/restore-data/restore-sql-server)"]]