Shadow copy considerations for restoring an application protection backup from the data mover

For Windows VMware virtual machines (VMs), if you attempt to restore an application protection backup from the data mover, be aware of shadow copy restrictions when you restore the application protection backup.

The shadow storage might run out of space

If you attempt to run a full VM restore of an application protection backup that was created with 2 or more snapshot attempts, the system provider snapshot is present on the restored VM. As the application writes to the disk, the shadow storage space grows until it runs out of disk space.

In general, if application protection was used during a backup, use only application protection restore. When you restore the application, the volume is automatically reverted. However, if you must restore the full VM, you must either revert or delete the shadow copy.

After you restore the entire VM, verify that the restore was successful, and the data is not corrupted. If the data is not corrupted, delete the shadow copy. If the data is corrupted, revert the shadow copy to restore data integrity.

You can determine which shadow copy to delete or revert by looking for the dsmShadowCopyID.txt file in the root directory of each restored volume. This file contains the snapshot IDs of the shadow copies that were created during the snapshot attempts. You can use the diskshadow command delete shadows to delete these IDs, or the revert command to revert the shadow copy. After the delete or revert is completed, you can also delete the dsmShadowCopyID.txt file.

Important: In order for the revert operation to succeed, the application database, such as the Microsoft SQL Server database or Microsoft Exchange Server database, must be on a non-boot drive (any drive other than the boot drive).

The shadow copy must be available on the restored volume during an application protection restore

In some cases, an application protection backup operation might use the Volume Shadow Copy Service (VSS) to create an application-consistent shadow copy before you start a VM backup. All changes that are made after the creation time of the shadow copy are saved to the shadow storage.

A database restore might fail if the shadow copy is not available during an application restore. The shadow copy is used at the time of restore to revert the restored volume to an application-consistent state. If the shadow copy not available, the restored data will be in an inconsistent state.

The following situations can cause the shadow copy to be unavailable:

Typically, the shadow storage is part of a volume. However, sometimes the shadow storage space is configured to be on a different volume either by default or manually. In this case, the database restore might fail because the shadow copy that was created during the VM backup operation is not available at restore time.
The shadow storage is not available because the volume with the shadow storage was excluded at backup time.

The following workarounds are available for this issue:

Before you run a VM backup, add the shadow copy storage association for each volume that is available on the guest VM by using the vssadmin add shadowstorage command. For example, to set the shadow storage location for volume E: on volume E:, issue following command:
```
vssadmin add shadowstorage /for=E: /on=E: /maxsize=unbounded
```
Important: The vssadmin add shadowstorage command might fail if the VM has existing VSS snapshots. You must delete the VSS snapshots by using the same application that created them.
For example, if a VSS backup of an Exchange database with LOCAL backup destination was created by IBM Spectrum Protect™ for Mail: Data Protection for Microsoft Exchange Server, use the Data Protection for Microsoft Exchange Server application to delete the VSS backup. If an unidentified VSS snapshot exists, use the Windows diskshadow command delete shadows to delete the VSS snapshot.

Also, ensure that the volume that holds the shadow storage is not excluded from backup operations.
Manually revert snapshots to achieve application-consistency of the database files:
1. Mount all disks in the VM backup by using IBM Spectrum Protect recovery agent.
2. Start the Windows diskshadow command in interactive mode.
3. In the interactive diskshadow mode, issue the following command:
```
list shadows all
```
4. In the root directory of each mounted drive, locate the ShadowCopyID.txt file. This file contains the globally unique identifier (GUID) of the VSS shadow copy that is needed in the volume revert operation.
5. Open the ShadowCopyID.txt file and identity the GUID of the volume where the database files are located.
6. In the interactive diskshadow mode, issue the following command:
```
revert GUID
```
  where GUID is the snapshot GUID that was identified in the ShadowCopyID.txt file.
In order for the revert operation to succeed, the application database must be on a non-boot drive.

Recovering from an application protect restore failure of a guest VM with Microsoft Exchange Server

Restoring a guest VM from an application protection backup can fail if the guest VM contains disks of different sizes and the original application protection snapshot of the VM took more than 10 seconds to complete.

This situation applies to application protection restore operations that fail when the /RECOVer=APPLYALLlogs AND /MOUNTDAtabases=Yes option is specified with the database restore command.

For example, a restore operation failed when the following Data Protection for Microsoft Exchange Server command is run:

tdpexcc restore DB1 FULL /mountdatabases=Yes /recover=applyalllogs

To resolve this problem, you must enable disk shadow copies for each disk in the guest VM and rerun the application protection backup. To avoid this problem in the future, enable disk shadow copies of each disk in the guest VM before you run application protection backups.

To recover from the restore failure, complete the following steps:

Ensure that the guest VM snapshot takes less than 10 seconds to complete.
If the snapshot takes longer than 10 seconds to complete, and the source disks on the guest VM are of different sizes, enable the shadow copies on each disk in the guest VM.
Run a guest VM backup on data mover machine.
Restore the databases again.

Important: If this problem occurs, the VM backup cannot be used to perform an application-consistent restore. You can perform only a crash-consistent restore. You must correct the configuration and run a new backup in order to have an application-consistent restore.