Frequently Asked Questions - SnapProtect for VMware
- How can we avoid dead paths after snapshot mounts?
- How do backup and restore operations handle independent/RDM disks?
- How do backup and restore operations handle virtual RDM disks?
- Using the Virtual Server iDataAgent in HotAdd mode configurations
- How can I limit VSA user access to specific resource pools or ESX hosts?
- How is capacity licensing calculated for virtual machines?
- Why is my backup data showing volume numbers instead of drive letters?
- Can we perform load balancing across datastores or volumes?
By default, when mounting a hardware snapshot to an ESXi host, a rescan is performed only for the specific adapter to which the LUN was exposed. If the ESXi host has multiple host bus adapters (HBAs) and has multi-pathing enabled, stale disk entries might be displayed on the secondary HBA after backups.
To enable all adapters connected to the host to be re-scanned, create the nRescanAllHBA additional setting on the VSA proxy and set the value to true. This setting can cause the rescan to take longer.
If a virtual machine undergoing a backup job includes independent disks or physical RDMs, those disks will be skipped.
If a subclient contains virtual machines with independent disks/physical RDMs, the backup job will always complete with the status "Completed w/ one or more errors". However, if you configure the IgnoreUnsupportedDisks additional setting on the proxy computer, the backup job will complete successfully.
If the Unconditionally overwrite VM with the same name option is used when restoring a virtual machine that has independent disks, the independent disks and their VMDKs are removed from the datastore and are not restored.
Virtual RDMs are protected by the backup job (but not during SnapProtect backup). However at the time of restore, the data is restored as a regular VMDK on a datastore. A virtual RDM is not re-created and the data is not restored to the virtual RDM’s device.
- When deploying the Virtual Server Agent, install the software on a datastore with the largest VMFS block size. This is necessary to ensure that the Virtual Server Agent can mount and back up virtual machines residing on all datastores.
- Helper virtual machines are not required for HotAdd Virtual Server Agent servers using VADP.
You can define users and provide them with role-based privileges in vCenter at any desired level: vCenter, datacenter, ESX host, resource pool, or virtual machine.
- On the vCenter server, define a local user who should have access to a specific level.
- In vCenter, define a role with the required permissions.
- At the desired level in vCenter, add permissions for the user and role.
- In the CommCell, add the user information to the Virtual Server instance properties.
For detailed steps, see Add a Custom User with Limited Scope.
Virtual machine backup job data for capacity licensing usage is calculated as follows:
- For streaming backups and backup copy jobs, the capacity usage is based on the guest size for all virtual machines being backed up.
- For SnapProtect backups, the capacity usage is based on the application size for the virtual machines being backed up.
In the License Summary Report, the Job Size column lists guest sizes for virtual machines included in full or synthetic full streaming backups (including backup copy jobs) and application sizes for snapshots.
Capacity usage is summarized as follows:
- Virtual machine streaming backups are included in the Backup license count (depending on the storage policy configuration).
- Backup copy operations are included in the Backup license count.
- Archived VMs are included in the Archive license count.
- SnapProtect backups are included in the Snapshot count.
When the same virtual machine is included in multiple backup jobs, only one of the jobs counts against capacity usage. If a virtual machine is included in multiple subclients, the latest backup provides the size included in overall capacity usage. If a virtual machine is included in both backups and archiving jobs, the guest size for the VM counts toward the Backup license.
Logical volume manager (LVM) metadata processing for volumes encrypted using BitLocker is currently not supported. Decrypting contents of such volumes may not be feasible during backup because decryption requires a recovery password or a decryption key. Because metadata collection for the volume fails, the reported guest size for virtual machines with encrypted volumes may be incorrect and a file-level browse operation for the encrypted volume cannot display file information.
When capacity licensing is used, the used space as reported by the guest OS for the virtual machine is reported against licensed capacity. For example, if the guest OS shows 20 GB used on a 100 GB disk, 20 GB is what counts against the licensed capacity. This is the case even if a different figure is reported for VM disks on the datastore, and is not affected by deduplication or compression.
For more information about virtual machine sizes, see Size Measures for Virtual Machines.
Verifying Backup Job Data for Virtual Machines
To review backup information for virtual machines, generate a VM Backup Report.
Alternatively, you can log in to the CommServe host using qlogin and run the following stored procedure on the CommServe database:
qoperation execscript -sn QS_CLAGetVSADetails –cs commserve_host_name –file file_name -format csv
The resulting output shows the size of the latest backup job for each virtual machine. The size value is the guest size for the VM, or the used space if guest size is unavailable; the size value for all VMs is used in the overall capacity licensing calculation.
The output also shows which license category each VM counts against, and provides instance, backup set, subclient, and job information for each VM.
If hard disk filtering was used for the backup and the drive that contains the operating system was excluded from the backup, the backup is unable to obtain information about drive letters. You can still browse and restore backed up files on the volumes that were backed up.
When backup jobs are run for multiple virtual machines (VMs), VMs are backed up sequentially, with each VM backup on a separate job stream. The number of simultaneous job streams can be limited through configuration for the storage policy and subclient, and by the number of available data paths for a datastore or volume where backup data is being written.
By default, the next VM to be backed up and assigned to a job stream is selected randomly from the list of VMs that remain to be backed up. This default selection can lead to performance issues when most of the backup jobs are writing to the same datastore or volume.
For streaming backups (including Backup Copy for SnapProtect), you can perform load balancing across datastores and volumes by setting nGetNextVMMethod on the Virtual Server Agent (VSA) proxy that performs the backup. When this parameter is set to 1, SnapProtect checks activity on datastores and volumes sequentially, based on each VM's primary datastore or volume, and selects the next virtual machine for backup for the datastore or volume with the smallest number of VMs being backed up by the current job.
To set the nGetNextVMMethod option:
- From the CommCell Browser, go to Client Computers | <VirtualizationClient>.
- Right-click the VSA proxy and select Properties.
- On the General tab of the Client Computer Properties dialog, click Advanced.
- On the Advanced Client Properties dialog, click the Additional Settings tab.
- Click Add.
- Add the following entry:
- Name: nGetNextVMMethod
- Category: Virtual Server
- Type: Integer
- Value: 1 (to perform load balancing across datastores and volumes)
- Click OK to save the additional setting.
- Click OK twice more to save the advanced client properties and the client properties.