It is recommended to create multiple backupsets for the same ESX server or vCenter when using Virtual Server iDataAgent with hardware snapshots. You can configure multiple backupsets as follows:
BackupSet 1 - Use this backupset only for snapshots and not for backup copies. This backupset will provide multiple recovery points and fast recovery from any point-in-time.
BackupSet2 - Use this backupset for regular backups. After performing the first full backup, you can keep on performing incremental backups. You can enable the DASH copy option while creating the secondary copy. The VMware's Change Block Tracking feature is used internally during regular backups. The Change Block Tracking and DASH copy enable faster backups.
This configuration has following advantages:
In case the Virtual Server iDataAgent is no longer required to run data protection operations, it is recommended to release the Virtual Server iDataAgent's license instead of uninstalling it. If the iDataAgent is uninstalled then you will not be able to do the following:
Use and run the default subclient regularly since it performs the VM discovery operations.
While the default subclient will be used regularly in most deployments, the following exceptions apply:
Creation of a Virtual Machine should be done for multiple subclients only. Creating one virtual machine per subclient can cause scheduling problems, and can become unmanageable in larger environments.
When deploying the Virtual Server iDataAgent for Hot-Add Mode Backups, choose the datastore with the largest VMFS block size to ensure backups can mount and back up virtual machines residing on all datastores.
When Change Block Tracking is unavailable, backups revert to Cyclic Redundancy Check (CRC) to determine changed blocks. Since the Virtual Server iDataAgent needs to read the entire virtual machine disk, CRC incremental backups may take almost as long as full backups even though the amount of data transferred and stored by an incremental backup is limited to the changed blocks within the virtual disk. Therefore, correcting CBT on the problematic virtual machine is recommended as quickly as possible to take full advantage of VADP-based incremental backups.
Tools are available to check the correct installation of the VDDK and for verifying and correcting CBT issues. Contact your software provider for information on obtaining these tools.
The Job Results directory stores the job results files from backup and restore operations of a client.
The user impersonation account specified for the job results directory will take precedence and will be used to backup and restore data from a virtual machine. This may result into file access related issues during the backup. Therefore, it is recommended to use a local folder on the client computer as the job results directory.
It is recommended to use a short name for an NFS datastore. When you perform the SnapProtect backup of an NFS datastore, Calypso can append up to 20 characters with the name of NFS datastore to create the volume label. The ESX server supports a volume label of 42 characters.
During the backup of any virtual machine, a snapshot of the virtual machine gets created on its datastore. If the datastore of any virtual machine doesn't have sufficient space for snapshots, the backup job completes with one or more errors. Before performing the backup, you can set a threshold of required free space by creating the nDatastorePercentageFreeSpace registry key. If a datastore doesn't have the required free space, the software will not perform backup of all the virtual machines residing in that datastore.
When you perform the backup of a subclient, a virtual machine will be skipped from the backup if its datastore doesn't have the required free space.
This is due to the fact that the Initiator group or the transport mechanism has cluster grouping. The clones are exposed to the existing transport mechanism having the cluster grouping where the rescan is done at the cluster level. Orphaned data stores with (_Gxbackup) will be exposed on all ESX servers and unmounts thereby not initiating a cleanup at the cluster level. Cleanup will be done only for the proxy ESX Server leaving behind stale data stores on other ESX Servers in a cluster.