Unitrends supports recovery of full, differential, and transaction log backups of SQL databases. See the following topics for details:
Recovery procedures vary depending on what type of database and backup are being recovered. Consider the following before recovering SQL backups:
Recovery type |
Requirements and considerations |
||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
All recovery operations |
The following apply to all SQL recovery operations:
|
||||||||||||||||||
User databases |
A full user database backup can be recovered to the original location or to an alternate location. The alternate location can be any available SQL server that has been added as an asset to the Unitrends appliance (and is running a SQL version that is the same or later than that of the original SQL application). The database may also be renamed and recovered to a specified alternate path if desired.
|
||||||||||||||||||
System databases |
The following apply to recovering system databases:
|
||||||||||||||||||
Clusters |
To recover a clustered database instance to an alternate location, you must select a path that is on a shared volume associated with that SQL instance. |
||||||||||||||||||
Stretch databases |
The backup must be recovered to the original database and instance. Only local SQL data is included in the backups. After recovering the local SQL data, you must reconnect the local recovered database to the remote Azure database to reconcile the recovered data. See To recover a Stretch database backup for details. |
||||||||||||||||||
Always Encrypted databases |
The SQL Column Master Keys (CMKs) must be available on the recovery target so you can access the recovered data. The keys are stored in a certificate on the SQL server. If the keys are not available on the recovery target, you must install them after you recover the backup. In most environments:
|
After you have reviewed the Considerations for recovering SQL backups, use one of the following procedures to recover a SQL backup or imported backup copy:
To import a backup copy, see To import a cold backup copy , To import a backup copy from the Unitrends Cloud or To import a hot backup copy from a Unitrends target appliance.
1 | Select Recover, and click the Backup Catalog tab. |
Use Filter Backups to the right to customize the backups that display.
2 | Expand the SQL server and database. |
3 | Select the backup or imported backup copy to recover. |
4 | Click Recover and select Recovery Options and Advanced Options |
Recovery Options |
Description |
|||||||||
---|---|---|---|---|---|---|---|---|---|---|
Recovery Target |
Select the asset where the database will be recovered. |
|||||||||
Recovery Instance |
Select the SQL instance to which you want to recover the database. Notes:
|
|||||||||
Database |
Enter a name for the recovered database. If the original SQL instance is selected and the database matches the original name, the original database files are overwritten during the recovery. Otherwise a new database is created. For system databases, the database name cannot be changed. |
|||||||||
Specify Path |
Select Specify Path to enable Browse. Select a path on the restore target. Notes:
|
|||||||||
Point-in-time Recovery |
(Optional) This option is available for transaction log backups only. For additional recovery points (down to the minute-level), check the Point-in-time Recovery box and select the desired recovery point by moving the Earliest/Latest slider. |
|||||||||
Commands to run pre-restore |
(Optional) Enter commands to be run before the recovery. |
|||||||||
Commands to run post-restore |
(Optional) Enter commands to be run after the recovery. |
5 | Click Next. |
6 | Click Save. |
Use this procedure to recover multiple databases to their original locations. To recover to a different location, use the To recover one SQL full, differential, or transaction log backup procedure instead.
1 | Select Recover, and click the Backup Catalog tab. |
Use Filter Backups to the right to customize the backups that display.
2 | Expand the SQL server and database. |
3 | Select the backups or imported backup copies to recover. |
• | You can select multiple databases that reside on the same host server. |
• | Each backup you select is recovered as a separate job. |
• | Databases are recovered to their original locations with their original names. Any existing data is overwritten. |
4 | Click Save. |
A SQL backup of a Stretch database must be recovered to the original database and instance. Because only local SQL data is included in the backup, you must reconnect the local recovered database to the remote Azure database to reconcile the recovered local data with data that has been migrated to Azure.
1 | Select Recover, and click the Backup Catalog tab. |
Use Filter Backups to the right to customize the backups that display.
2 | Expand the SQL server and database, then select the desired backup or imported backup copy. |
3 | Expand the database, and select the backup to recover. Use filter options as necessary to locate a specific database. |
4 | Click Recover and select these Recovery Options and Advanced Options: |
Recovery Options |
Description |
---|---|
Recovery Target |
Select the original SQL server asset (where the database was backed up). |
Recovery Instance |
Select the original SQL instance that was backed up. |
Database |
Enter the name of the original database. Note that existing database files are overwritten during the recovery. |
Specify Path |
Leave this field empty. Files will be recovered to their original locations. |
Commands to run pre-restore |
(Optional) Enter commands to be run before the recovery runs. |
Commands to run post-restore |
(Optional) Enter commands to be run after the recovery runs. |
5 | Click Next. |
6 | Click Save. |
The backup is recovered to the original location, creating a new SQL server database.
7 | Follow the instructions in Microsoft's Backup and restore Stretch-enabled databases article to connect the newly recovered database to Azure and reconcile the local recovered data with the Azure database. Note the following: |
• | For credentials, you will need to supply the Azure SQL database FQDN credentials that were created when the original SQL database was stretched. (Do not use the Azure SQL Server administrator credentials.) |
• | Stretch database credentials are stored on the SQL server and are encrypted with a SQL Master Key. If credentials have been lost, you must recreate them manually using the master key before you can connect the recovered database to the remote Azure instance. |
• | Connecting the newly recovered database causes a new copy of the remote Azure database to be created. |