You can validate backups of VMware guest virtual machines, including VMs that run applications. Validation performs a live mount operation for the VM, and can also run a script to verify that the VM and application are usable.
You can use validation to verify that backups are available in the event that you need to restore application data from a backup, or to replicate VMs and applications for use in the event of a disaster.
Note: This feature was previously called "backup validation."
You can use validate protected VMs from streaming, IntelliSnap-enabled VM groups with Live mount supported snapshot vendors and engines as listed in the Intellisnap Support for Live Mount topic. Validation applies to the backup copy and its secondary copied data. For engines where Live Mount is not supported, use the primary or secondary copy as the source to validate VMware guest VMs, including VMs with applications.
You can perform validation automatically as part of the schedule for the VM group, or by requesting validation for a specific VM or for a VM group that has validation enabled.
If validation fails for an incremental backup, repeat the operation with a full backup.
For the hypervisor or for the recovery target that is used for this feature, you can specify a Windows or Linux access node (VSA proxy). To run scripts and validate applications, you must use a Windows access node.
The following options are not supported from a snapshot copy, but these options are supported when primary or secondary copies are used as the source in an application validation configuration:
keeping the validated virtual machines running
maximum number of threads
custom validation scripts
You can use the script provided with the Virtual Server Agent to validate VMs that run Microsoft SQL Server. By default, the SQL Server script logs on, verifies that services are running, and executes SQL queries to enumerate the databases. If the application validation is successful, the script return code is 0. In addition, the details for the backup job indicates whether validation was successful.
You can modify the SQL Server script as needed, or create a new script that can be used to validate the VM or a different application.
Live mount operations use a 3dfs cache on the MediaAgent that performs the live mount. By default, the 3dfs cache is located in the Job Results folder for the MediaAgent; but you can change the path using the s3dfsRootDir additional setting. The 3dfs cache is circular; unused data are pruned from the cache as needed. By default 5% free space is maintained on the cache; but you can change the required percentage of free space using the n3dfsCacheMinFree additional setting.
For each live mount job, the 3dfs cache requires minimum free space equal to the larger of the following values:
15% of the total VM size (the sum of the sizes of all VMDKs for the VM)
Note: For faster recovery times, the 3dfs cache should be hosted on a solid state drive (SSD) using flash memory storage.
To validate backups, perform the following tasks:
A recovery target is required for non-admin users. If no recovery target exists, administrators can enable the Use source VM ESX to mount option for backup validation.
Create a separate VM group for each set of VMs that run a particular application.
For example, you can create one VM group for VMs that run SQL Server, and a separate VM group for VMs that run Microsoft Exchange.
Edit the VM group configuration to enable backup validation.
As needed, create custom validation scripts for applications.
When you enable backup validation, you can identify a custom validation script for the applications running on the VM.
A script that can be used to validate a VM that runs SQL Server is included with the Virtual Server Agent, and is located on VSA access nodes in the C:\Program Files\Commvault\ContentStore\Base folder. You can modify that script as needed, or create a new script that can be used to validate the VM or a different application.