NetBackup for VMware: notes and restrictions
Note the following about NetBackup for VMware:
For information on supported VMware versions and on supported platforms for the backup host, see the NetBackup Enterprise Server and Server OS Software Compatibility List available from the following location:
NetBackup Master Compatibility List
For additional support information on NetBackup for VMware, see Support for NetBackup in virtual environments:
NetBackup for VMware does not support the option on the policy Attributes tab of the Administration Console.
NetBackup supports these features as follows:
For Instant Recovery, use the nbrestorevm command.
For SLP management of snapshots, use Replication Director.
For more information, see the NetBackup Replication Director Solutions Guide.
NetBackup allows up to 31 snapshots per virtual machine. If the virtual machine has more than 31 snapshots, the backup may fail with status 13. Messages similar to the following appear in the NetBackup job details:
10/18/2012 4:56:59 PM - Critical bpbrm(pid=4604)from client Umesh_w2k3_hypervm33: FTL - vSphere_freeze: Unable to remove existing snapshot, too many existing snapshots (91). 10/18/2012 4:56:59 PM - Critical bpbrm(pid=4604) from client Umesh_w2k3_hypervm33: FTL - VMware_freeze: VIXAPI freeze (VMware snapshot) failed with 26: SYM_VMC_REMOVE_SNAPSHOT_FAILED
As a reminder to consolidate or delete snapshots, the NetBackup detailed status provides the following message when the number of snapshots exceeds 15:
Umesh_w2k3_hypervm33: WRN - vSphere_freeze: VM has 16 existing snapshots. Snapshots may start failing if this number exceeds 32
To back up a virtual machine that has more than 31 snapshots, consolidate or delete the existing snapshots. Then rerun the backup.
Note:
Replication Director backups allow more than 31 snapshots per virtual machine.
If the number of snapshot delta files for a VM's vmdk exceeds 32, snapshot creation fails. A message similar to the following appears in the NetBackup detailed status:
Umesh_w2k3_hypervm33: FTL - vSphere_freeze: Unable to proceed with snapshot creation, too many existing delta files(50).
As a reminder to consolidate or delete snapshots, the NetBackup detailed status provides the following message when a vmdk's delta files exceed 16:
Umesh_23k3_hypervm33: WRN - vSphere_freeze: VM has 17 existing delta files for vmdk Umesh_23k3_hypervm33.vmdk. Snapshots may start failing if this number exceeds 31
Delta files can accumulate if the VM's snapshots are not deleted or consolidated. Consolidate or delete the existing snapshots, then rerun the backup.
NetBackup for VMware cannot back up the data on an independent disk, because an independent disk cannot be captured with a snapshot. The backup succeeds but the backup image contains no data for the independent disk.
To back up the data on an independent disk, install a NetBackup client on the virtual machine. You can configure NetBackup to back up the virtual machine and any independent disks as if the client was installed on a physical host. You can restore the virtual machine and then restore the independent disk as a separate job.
NetBackup for VMware does not back up standard iSCSI LUNs that are connected to the virtual machine. If the virtual machine has an iSCSI LUN, the backup succeeds but the drive that represents the LUN is not backed up.
Note: NetBackup for VMware supports datastores over iSCSI.
Several notes and limitations apply to Linux virtual machines.
If a Windows virtual machine includes Veritas Storage Foundation volumes, the option is not supported.
See Storage Foundation Volume Manager volumes in the virtual machine.
During an incremental backup with the option (with or without block-level incremental backup), any files that had been moved or renamed are not backed up. Those files are not available when you browse to restore individual files from that incremental backup.
Note:
When you restore the entire VM from a block-level incremental backup, the file metadata is updated and the moved or renamed files reflect the updated metadata.
VMware virtual machine templates are for cloning virtual machines: They cannot be turned on and used as functioning VMs. As a result, VMware has imposed the following restrictions on backup and restore of virtual machine templates:
A virtual machine template cannot be captured in a snapshot. NetBackup backs up the template to the designated storage unit.
Block level incremental backup (BLIB) cannot be used when backing up a virtual machine template.
Note:
As a result of this restriction, NetBackup Accelerator cannot be used to back up VMware virtual machine templates.
A virtual machine template cannot be backed up over a SAN. You must configure the NetBackup policy to use a local network transfer type, such as nbd. Likewise, the restore of a template must be conducted over a local network.
Note:
You can use the Query Builder in the NetBackup policy to create rules for automatic selection of virtual machine templates.
NetBackup supports non-ASCII characters in virtual machine objects, as follows:
The NetBackup master server, the backup host, and the restore host must run NetBackup 8.1 or later. The backup host and the restore host may be the same computer.
The UNIX and Linux operating systems on the NetBackup master server, the backup host, and the restore host must use UTF-8 character encoding. The backup host and the restore host may be the same computer.
The name that NetBackup uses to select a VM for backups cannot contain non-ASCII characters. The field in the backup policy identifies the name type that NetBackup uses to select VMs. For example, if you specify as the , the display name of each VM that you back up cannot contain non-ASCII characters.
See Primary VM identifier options (VMware).
and names never contain non-ASCII characters.
For security purposes, VM names have some restrictions.
See NetBackup character restrictions for the Primary VM identifier.
Examples of objects are file and folder names, annotations, floppy image name, parallel port or serial port file name, CD-ROM ISO name, and so on.
For dual-boot virtual machines, NetBackup does not support the following policy options:
Enable file recovery from VM backup
Exclude deleted blocks
Exclude swap and paging files
Exclude boot disk
Exclude all data disks
To support the following exclude disk options, the backup host must be at release level 8.1 or later:
Perform custom attribute based exclusion
Custom Attribute based disk exclusion requires that you enter in NetBackup the credentials for the vCenter server or servers that host the VMs. ESXi server credentials are not sufficient.
Specific disk(s) to be excluded
NetBackup does not support the following exclude disks options for Replication Director backups:
Exclude boot disk
Exclude all data disks
Perform custom attribute based exclusion
Specific disk(s) to be excluded
If you remove a disk from exclusion, the individual files that were last modified before the most recent backup cannot be restored. To restore those files, restore the entire virtual disk or the virtual machine. After the next full backup, those files are available to restore individually.
NetBackup fails the backups of virtual machines that are empty. A VM may be empty because all of its disks are empty or because disk exclusion excludes all disks.
To back up a virtual machine while Storage vMotion migrates its files, NetBackup must conduct the backup through the vCenter server.
See Conflict between NetBackup and VMware Storage vMotion with vSphere 5.0 or later.
Several notes and limitations apply to the automatic selection of virtual machines for backup (Virtual Machine Intelligent Policy).
See NetBackup requirements for automatic virtual machine selection.
For hotadd backup or restore: The virtual machine to back up (or restore) and the virtual machine that contains the hotadd backup host must reside in the same VMware data center.
NetBackup for VMware supports Windows NTFS file encryption and compression, for backup and restore. However, NetBackup for VMware does not support NetBackup's compression or encryption options (in the NetBackup policy attributes).
For Windows, UNIX, or Linux guest operating systems: NetBackup for VMware does not support any type of compression or encryption, whether they are set in NetBackup or in the guest OS (such as BitLocker).
Note:
The compressed Windows NTFS files are backed up and restored as compressed files.
Storage optimization cannot be used if a snapshot exists on the virtual machine when VMware Changed Block Tracking is turned on.
If the policy's option is set to VM hostname, note: NetBackup cannot select a VMware virtual machine for backup if it cannot obtain an IP address for the virtual machine.
For Exchange, SharePoint, and SQL applications, NetBackup for VMware supports Granular Recovery Technology (GRT) restores from full backups only.
If a policy is changed from manual selection to Intelligent policy (or vice versa), the next backup of the VM is a regular full backup, even if a backup already exists for that VM.
For example:
In a new VMware policy, the option on the Clients tab is used to select a VM. The first backup from the policy runs.
In the policy, an Intelligent Policy query is used to select the same VM, and the VM is backed up a second time. Because of the switch from manual selection to query-based selection, this second backup is a regular full backup. Note that for a policy that uses (BLIB) or BLIB plus Accelerator, the backup processing is not limited to changed blocks only.
For the second backup, the Detailed status log includes a message similar to the following:
There is no complete backup image match, a regular full backup will be performed.
The same backup behavior occurs if the policy's VM selection is switched from query-based to manual selection: The second backup is a regular full backup.
For the virtual machines that vSphere 6.5 hosts, NetBackup fails the backup if a snapshot exists while NetBackup tries to enable VMware Change Block Tracking. Because the VMware Change Block Tracking API behavior changed beginning in vSphere 6.5, NetBackup fails the backup.
NetBackup enables CBT on a VM if is enabled in the backup policy and CBT is not enabled already on the VM.
In vSphere, if your virtual environment has IPv6 addresses, use only fully qualified domain names (FQDNs) that are mapped to IPv6 addresses on the DNS server.