You can restore data from the primary copy associated with the server plan or from a secondary copy (such as auxiliary copy or NetApp Open Replication).
-
Restore operations from streaming VSA backups read application data from the snapshot copy that is defined for the server plan or from a secondary copy.
-
For restore operations from IntelliSnap backups, by default, data is restored from the snapshot copy.
Important
-
To restore an application database, initiate a browse and restore operation from the application.
-
Both the VSA job and the associated application job must be available when you restore data for an application. The point-in-time software snapshot that is created by the application backup operation is part of the data that is stored for the VSA backup job. Ensure that both the VSA job and the application job are retained in the same storage policy copy that is used for restore operations.
By default, the VSA proxy that was used for the backup (or the next available VSA proxy) is also used for the restore.
Note
-
Do not use a MediaAgent to perform a VM-level live browse operation at the same time as the same MediaAgent is being used for an operation to browse or restore granular data from an application-aware backup for Exchange or SharePoint.
-
If you try to recover an Exchange or SharePoint database when a request to browse or restore granular data from an application-aware backup is in progress, and you receive an error message indicating the VSS snap was not found, retry the operation.
-
If you want to perform an out-of-place restore operation, then the MediaAgent package must be installed on the destination client.
Disaster Recovery
In most cases, you will restore the application database in place. If you need to recover the VM and the application, you can restore the VM first through the VM group, then recover the database in place on the restored VM.
Application Data Restores from VSA Streaming Backups
For restores from streaming application-aware backups for Windows VMs, a block-level driver mounts a pseudo-disk on the MediaAgent that is used for browse and restore operations. The restore gets file system information from the pseudo disk, enabling browse and restore operations to read directly from stored backup data.
By default, Windows VMs use MediaAgent binaries that are included with the application plug-in.
For Linux VMs, the mount happens on the VSA Linux proxy that is used for the restore.
Block-Level Restores
Restores from streaming VSA application-aware backups are block-level restores.
Restrictions:
-
Unless otherwise noted for a particular feature, block-level browse (also called live browse) and block-level restores are not supported from backups to tape libraries or virtual tape libraries.
-
Block-level browse is not supported on VM disks that have a mount point instead of a drive letter.
-
Due to a Microsoft limitation, block-level browse is not supported on ReFS volumes if the MediaAgent used for the browse is running on a Microsoft 2008 R2 server or earlier version.
To restore from a secondary copy on tape libraries or virtual tape libraries, move the copy to disk storage before performing the restore.
Application Data Restores from VSA IntelliSnap Backups
For restores from application-aware backups performed with IntelliSnap, the application plug-in first mounts the VSA hardware snapshot and then attaches the disk. By default, the snapshot is mounted to the source VM. The application plug-in restores application data, then detaches the disk and unmounts the snapshot.
When Destination VM Does Not Have Access to Snapshots
If the destination VM does not have access to VSA hardware snapshots, you can perform a restore from the CommCell Console using the following option during the restore operation from the application client:
-
From the Restore Options dialog box, click Advanced.
The Advanced Restore Options dialog box appears.
-
On the Data Path tab, select a VSA proxy from the Use Proxy list.
This selection ensures that the VSA proxy can mount hardware snapshots and attach disks. For VMware, the VSA proxy should be running on a VM on the same vCenter as the destination VM.
Note
If the destination VM is a highly-available client node, mount the snapshot on the VSA proxy instead of the destination VM. Because the VM where the snapshot is attached is taken offline while disks are attached, using the destination VM for the mount operation could result in a failover.
Restoring to a Different vCenter
Before you restore application data to a VMware VM on a different vCenter than the source VM, perform the following steps for the VSA subclient for the source VM from the CommCell Console:
-
From the CommCell Browser, go to Client Computers > virtualization_client > Virtual Server > VMware > backup_set.
-
Right-click the subclient and click Properties.
-
On the Advanced Options tab, select the destination vCenter from the Virtual Center/ESX Server list, and specify the destination host as the Snap Mount ESX Host.
Snapshot Mounts from the CommCell Console
If you manually mount a snapshot, the destination client must be a VSA proxy that meets the requirements for application-aware backups using IntelliSnap.