Information below describes environmental requirements, job setup best practices and the backup process for VMware Virtual Machine (VM) backups and Backup Exec's Agent for VMware Virtual Infrastructure (AVVI).
Configuring SAN-based backups (not restores) with Backup Exec Agent for VMware Virtual Infrastructure is relatively simple after following some basic guidelines:
- For performance reasons, it is recommended that only one Backup Exec server be zoned to see a set of VMFS LUN’s at one time.
- Zone the LUN’s containing the VMFS datastore so the Backup Exec server can see and access them.
- LUNs should show as "unknown volumes" in disk manager on BE server.
- LUNs should be presented to the BE server with read/write ability.
- Do NOT write a signature or assign a drive letter to these "unknown volumes"
- On the Backup Exec server, ensure that the “automount disable” and “automount scrub” commands have been run to disable automatic drive letter assignment
- To disable automount
- 1. Open a new command prompt
- 2. Type diskpart
- 3. At the prompt, type automount disable
- 4. The computer will display the message "Automatic mounting of new volumes disabled"
- 5. Type exit
- Confirm the following dword registry key is set to 1 (disabled)
- To disable automount
- As a result of the “automount disable” and “automount scrub” commands having been run, the VMFS datastore LUN’s should appear in Windows Disk Administrator as “unknown”. Do not attempt to mount, partition, or format these disks.
- Note : Sometimes it may not show as " Unknown " , but it will have no drive letter assigned to it.
BE server has connectivity to both the ESX host and vCenter servers
- BE server should be able to ping ESX host and vCenter servers
- Recommendation: ESX hosts have two NICS, one for vLAN and another dedicated to BE console traffic
- When adding new non-VMFS disks (NTFS drives/SAN) to VMware environment, the Non-VMFS datastore LUN’s will need to be mounted manually on the Backup Exec server (does not automatically mount disks)
AVVI best practices for backup jobs:
- Full with differential/incremental backups of virtual machines need to be created in a policy
- Select the vCenter/ESX host in the selection list and then exclude any virtual machines/templates you do not want in the backup (this will allow dynamic inclusion should the vmdk(s) be moved between servers).
SAN backup process:
Example job: Select the virtual machine(s) through vCenter with all GRT enabled and using SAN transport mode.
The following articles are also recommended:
- http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1035096 [Best practices when using SAN transport for backup and restore]
- Backup Exec backup job starts
- Backup Exec tells VMware to create a snapshot of VMDK through vCenter
- vCenter creates and mounts the snapshot to the datacenter and it now becomes the "active" snapshot (virtual machine is now running from that snaphsot)
- Backup Exec then gets the ESX host and guest virtual machine information from vCenter it needs to access or backup
- Backup Exec opens a connection with the ESX to ask for the virtual machine metadata
- Using vStorage APIs, Backup Exec then opens a direct data connection to the “unknown” SAN volumes and the virtual machine data is offloaded directly to the media server for backup
- “Extracting the Backup Data from the Target Virtual Machine”
- “Deleting the Temporary Snapshot”
- Once the backup completes, Backup Exec disconnects from the ESX host and vCenter
- Backup Exec runs a verify (by default) of the data backed up
- Backup job completes.