Prerequisites for Backing Up VMware VMs

Agentless VMware Backup is designed to skip VMs that have the Catalogic DPX agent installed. However, this behavior requires that VMware Tools is installed on the node before Catalogic DPX is installed and the option enabled in the backup settings. See . If these requirements are not met, Agentless VMware Backup will back up the node.
Note the difference between a snapshot and a native VMware snapshot. A snapshot displays as a backup instance in the management console and is the source for a restore. A native VMware snapshot is temporary and does not display in the management console.
Application aware protection is not currently agentless, see . It requires the Catalogic DPX application agents in the VMs to be backed up and a Block backup job.
Catalogic DPX requires Change Block Tracking enabled in the VM. If change tracking is not enabled, Catalogic DPX enables it before proceeding with the backup. If change tracking is disabled in the VM between backups, Catalogic DPX enables it again for the next backup.
In some cases, if you change a VM name after a backup is defined and run, the next backup may be a base backup, because the renamed VM appears as a new machine. The type of backup depends on the level of VMware object selected for backup:
- If the VM is explicitly selected in the backup job and the VM name is later changed, the backup job fails.
- If a higher level VMware object, such as datacenter, is selected for backup, the backup succeeds and is incremental, even though the VM name is changed.

Attention! If you perform storage migration of a VM in power off mode, you must power on the VM at least once before a backup, otherwise the backup fails.

For base backups, in most cases only allocated blocks are transferred. However, in certain cases, VMware does not support generating the list of allocated blocks in a VMDK. In these cases, the backup transfers all the blocks in the VMDK to secondary storage. The following are the cases where a list of allocated blocks is not generated and where consequently transfer of all blocks, including unallocated blocks, occurs:
- The VMDK is not in a VMFS datastore.
- The VMDK is a virtual compatibility RDM disk.
- The VMDK is created as a result of a VM clone operation.
- The VMDK is created using vmkfstool using eagerzeroedthick format.
- The VMDK is formatted using Long Format settings.
- The VM has one or more snapshots before Catalogic DPX enables Change Block Tracking (CBT) for the backup.
Incremental backups are not affected by this set of constraints. For incremental backups, in all cases only changed blocks are transferred.
For documentation of this VMware limitation related to CBT, read VMware knowledge base article .
For further data reduction, NetApp deduplication and data compression capabilities can be applied to stored backup data. For more information on the effect of data compression, see .

Last updated 1 year ago

Agentless VMware Backup is designed to skip VMs that have the Catalogic DPX agent installed. However, this behavior requires that VMware Tools is installed on the node before Catalogic DPX is installed and the option enabled in the backup settings. See . If these requirements are not met, Agentless VMware Backup will back up the node.
Note the difference between a snapshot and a native VMware snapshot. A snapshot displays as a backup instance in the management console and is the source for a restore. A native VMware snapshot is temporary and does not display in the management console.
Application aware protection is not currently agentless, see . It requires the Catalogic DPX application agents in the VMs to be backed up and a Block backup job.
Catalogic DPX requires Change Block Tracking enabled in the VM. If change tracking is not enabled, Catalogic DPX enables it before proceeding with the backup. If change tracking is disabled in the VM between backups, Catalogic DPX enables it again for the next backup.
In some cases, if you change a VM name after a backup is defined and run, the next backup may be a base backup, because the renamed VM appears as a new machine. The type of backup depends on the level of VMware object selected for backup:
- If the VM is explicitly selected in the backup job and the VM name is later changed, the backup job fails.
- If a higher level VMware object, such as datacenter, is selected for backup, the backup succeeds and is incremental, even though the VM name is changed.

Attention! If you perform storage migration of a VM in power off mode, you must power on the VM at least once before a backup, otherwise the backup fails.

For base backups, in most cases only allocated blocks are transferred. However, in certain cases, VMware does not support generating the list of allocated blocks in a VMDK. In these cases, the backup transfers all the blocks in the VMDK to secondary storage. The following are the cases where a list of allocated blocks is not generated and where consequently transfer of all blocks, including unallocated blocks, occurs:
- The VMDK is not in a VMFS datastore.
- The VMDK is a virtual compatibility RDM disk.
- The VMDK is created as a result of a VM clone operation.
- The VMDK is created using vmkfstool using eagerzeroedthick format.
- The VMDK is formatted using Long Format settings.
- The VM has one or more snapshots before Catalogic DPX enables Change Block Tracking (CBT) for the backup.
Incremental backups are not affected by this set of constraints. For incremental backups, in all cases only changed blocks are transferred.
For documentation of this VMware limitation related to CBT, read VMware knowledge base article .
For further data reduction, NetApp deduplication and data compression capabilities can be applied to stored backup data. For more information on the effect of data compression, see .