Recovering SQL backups

The following apply to all SQL recovery operations. See the remainder of this table for additional requirements by backup mode and database type.

●   The entire database is recovered in a live state with each recovery operation. Unitrends does not support granular recovery of SQL database records.

●   A database must be recovered to a SQL instance that is the same version or later than that of the original SQL instance. Databases cannot be recovered to an older SQL version.

●    During recovery, you select a SQL asset and instance where the database will be recovered. Eligible targets that have been added to the appliance display in the UI. For SQL, the Recovery Target list includes all SQL server and/or SQL cluster assets that are hosting at least one eligible database instance. (If needed, you can add a SQL server or cluster asset before you recover the backup. For details, see SQL backup requirements and considerations or Start protecting SQL clusters and availability groups.)

●   Any existing database of the same name that resides on the recovery target is overwritten during the recovery operation (even if you specify a different path). To retain the original database, you must modify the recovery database name in the Create Recover Job dialog.

The following apply to recovering full backups of SQL user databases:

●   A full backup can be recovered to the original location (the instance where the backup was taken) or to an alternate location.

●   If applicable, see Recovery to a clustered instance, Availability groups, Stretch databases, or Always Encrypted databases for additional requirements.

The following apply to recovering SQL differential or transaction log backups:

●   A local backup can only be recovered to the original location (the instance where the backup was taken).

●   An imported backup copy can only be recovered as the original name and to the original location (the instance where the backup was taken).

●   During recovery, all previous backups in the group are also recovered. This means that when recovering a transaction backup, all previous transaction backups, the latest differential (if any), and the parent full are also recovered. Each backup is recovered as a separate job, and all jobs in the group are queued automatically.

●   Transaction log backups – It is highly recommended that you synchronize the date and time of the SQL server with that of the Unitrends appliance before you start the recovery.

●   If applicable, see Recovery to a clustered instance, Availability groups, Stretch databases, or Always Encrypted databases for additional requirements.

The following apply to recovering system databases:

●    The master, model, and msdb system databases can only be recovered to their original SQL instances and names. The recovery job overwrites the existing database (even if you specify a different path).

●   The master, model and msdb databases must be recovered individually.

●   To recover the master database, you must first stop the SQL instance. See the Microsoft TechNet article How to Stop an Instance of SQL Server for details.

In a SQL cluster, a SQL Server failover cluster instance is installed into a Windows Server Failover Cluster (WSFC). The cluster's databases reside on shared storage that is accessible to each server node.

When recovering a SQL backup to a clustered instance, you must recover to a clustered storage resource that is accessible to all nodes in the cluster, and is a dependency of the SQL clustered instance you are restoring to. As long as you leave the Specify Path field empty (on the Create Recover Job dialog), the backup is recovered to the original clustered storage resource. If you enter a path, be sure to specify a clustered storage resource that is a dependency of the SQL clustered instance you are restoring to. (If you specify a local volume, the recovery fails with a SQL VSS Writer error.)

NOTE  Because it is the instance that is clustered, and not the hosted database, a backup taken on a clustered instance is no different than one taken on a non-clustered instance. As with all user database backups, a full can be recovered to any eligible instance (which can be clustered or non-clustered), and a differential or log backup must be recovered to the original location.

These additional requirements apply to recovering availability group databases.

Before you recover, ensure that these SQL prerequisites have been met:

●   The database must not be present in an availability group on the target server. If the database already exists, you must remove it from the availability group, then delete the mirrored copies from all secondary replicas.

●   A database of the same name that is in the restoring state must not be present on the target instance. If found, you must delete the database before running the recovery.

●    A differential or transaction log backup must be recovered to the original instance, and this instance must have an availability group that is configured with the same listener IP address as the backup's Availability Group asset. (For more on SQL assets, see Protecting SQL clusters and availability groups.)

After recovery, you must manually reconfigure the mirrors and add the recovered database to the availability group. See Microsoft's documentation for details.

A stretch database can only be recovered to its original SQL instance and name. The recovery job overwrites the existing database (even if you specify a different path).

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 by using the Backup Catalog for details.