Veritas NetBackup™ 8.0 for VMware Administrator's Guide

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:

  http://www.veritas.com/docs/000006177

• NetBackup for VMware does not support the Retain snapshot for Instant Recovery or SLP ... option on the policy Attributes tab of the Administration Console.

  NetBackup supports these features as follows:

  • For Instant Recovery, use the nbrestorevm command.

    See About Instant Recovery for VMware.

  • 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.

  See NetBackup for VMware: notes on Linux virtual machines.

• If a Windows virtual machine includes Veritas Storage Foundation volumes, the Enable file recovery from VM backup option is not supported.

  See Storage Foundation Volume Manager volumes in the virtual machine.

• During an incremental backup with the Enable file recovery from VM backup 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.

• VMware does not support non-ASCII characters in virtual machine display names or in other objects that are associated with the virtual machine. (Examples are annotations, floppy image name, parallel port or serial port file name, and CD-ROM ISO name.) Note that the same character restrictions also apply when creating vCloud Director objects.

  For VMware's list of the special characters that may cause issues, see the following VMware article:

  Troubleshooting issues with virtual machines or datastore names containing special characters (2046088)

  http://kb.vmware.com/kb/2046088

  For a list of objects that VMware does not support with non-ASCII characters, see the following VMware article:

  Troubleshooting errors resulting from non-ASCII names (1003866)

  http://kb.vmware.com/kb/1003866

  In keeping with VMware's position, NetBackup does not support non-ASCII characters in display names or in other vSphere objects. Veritas recommends that you follow VMware's guidelines in naming vSphere objects.

  In addition, NetBackup has its own restrictions on characters in display names.

  See NetBackup character restrictions for virtual machine display names and other vSphere objects.

  Note:

  If the virtual machine display name contains non-ASCII characters, the backup may succeed but the restore fails. To restore the virtual machine, configure a restore to an alternate location. On the Recovery Options dialog, change the display name to contain ASCII characters only.

• 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 (Advanced)

  • Exclude data disks (Advanced)

• NetBackup for VMware does not support the display names that end in a period. If the policy's Primary VM identifier option is VM display name, any VM with a period at the end of the name is not backed up.

• 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.

  See Notes on the hotadd transport mode.

• 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.

  See About reducing the size of VMware backups.

• If the policy's Primary VM identifier 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.

• Exchange, SharePoint, and SQL Server databases are not cataloged and backed up if they exist in mount point volumes.

• See Restore notes and restrictions.

• 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 Select manually 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 Enable block-level incremental backup (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.