All virtual machines in a specific datastore can be backed up and restored together as follows:
Refer to the following for complete step-by-step instructions:
The above-mentioned steps can also be customized to group backups and restores of other entities, such as ESX Server, Resource Pools, etc.
If you are performing a full backup of virtual machines which have thin provisioned disks on NFS datastore, the backup throughput may be less than a VMFS datastore. VMware does not support the retrieving allocated blocks on NFS volume. Therefore, during the full backup, the software reads the complete disk and writes only valid data blocks on the media and ignores the white spaces. This reduces the backup throughput during the full backup. In case of incremental backups, software uses Change Block Tracking (CBT) and thus reads and backs up only the changed data.
For more information, refer to “Changed Block tracking on Virtual disks" section in the following document:
http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vddk51_programming.pdf
If the Thin provisioned disk is on VMFS volume, the software reads and backs up only the allocated part of the disk.
If you change a virtual machine's GUID when you migrate the virtual machine from one storage location to another, auto discover does not recognize the migrated virtual machine, and the virtual machine is no longer automatically backed up.
Virtual machines can be excluded from backups by using regular expressions to filter them out during the discovery process. There are two ways to do this:
For example, if you only want to back up virtual machines with names beginning with win and sql, then you can create a user-defined subclient with the expressions *win* and *sql* assigned to it. Thus, only virtual machines containing these expressions in their names will be backed up.
Note, however, that the default subclient does not support regular expressions for excluding virtual machines from backups.
For more information on discovery options, refer to Advanced - VMware Configuration.
Folders residing in specific drives cannot be filtered during vSphere VADP file-level backups. You can, however, replace the drive letter in the filter with an asterisk ('*'). Note, however, that this option will filter out the selected folders and files from all drives.
For Example:
[*:\**\Windows*\**]
[*:\**\Program Files*\**]
Also note that global filters are not supported with volume-level backups.
If there are multiple virtual machines with same GUID:
You can restore multiple virtual machines from the backup set level as long as you are restoring the virtual machines to a different destination. If you want to perform in-place restore of multiple virtual machines, you must perform the browse and restore operation at the subclient level and not at the backup set level.
If the GUIDs of the virtual machines associated to a subclient are modified:
Yes, virtual machines created with vCloud Director are supported for backups, including SnapProtect. No special configuration is required. In addition to the standard protection and recovery capabilities, affinity-based automatic discovery can leverage Organization and Virtual Data Centers as discovery criteria as those entities appear as resource pools. Full virtual machine and vApp restores are supported, including single-file recovery.
After performing an In-place restore, the first run backup job will always be converted to a Full backup. The system assumes that it is a newly created virtual machine and hence defaults to a full backup.
Version 5.0 update 2 of the VDDK is supported for backups if it is installed manually in Virtual Server iDataAgent proxy machines, and is automatically installed with Service Pack 6A or higher.
To install a newer version of VDDK on a 32-bit computer, perform the following steps:
For example, C:\Program Files\VMware\VMware Virtual Disk Development Kit
To install a newer version of VDDK on a 64-bit computer, perform the following steps:
For example, C:\Program Files (x86)\VMware\VMware Virtual Disk Development Kit
For example, C:\Program Files\VMware\VMware Virtual Disk Development Kit\
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Virtual Disk Development Kit\InstallPath
with the following string value: (this should be the path created in Step 2)
C:\Program Files\VMware\VMware Virtual Disk Development Kit\
If a virtual machine undergoing a backup job includes independent disks, physical or virtual RDMs, these disks will be skipped. During a full VM restore the independent disk/Physical or virtual RDMs will get restored as a regular disk with 0MB data.
If a subclient contains virtual machines with independent disks/physical or virtual RDMs, the backup job will always complete with the status "Completed w/ one or more errors". However, if you create the IgnoreUnsupportedDisks registry key on the proxy computer, the backup job will complete successfully.
Virtual RDMs are protected by the backup job (but not during IntelliSnap backup). However at the time of restore, the data is restored as a regular VMDK on a datastore. A virtual RDM is not re-created and the data is not restored to the virtual RDM’s device.
In an isolated network, add an additional network connection to the proxy computer.
VDDK 1.2 is installed to the Base folder with the Virtual Server iDataAgent. Software version 8.0 Virtual Server iDataAgent machines that were upgraded to v9 will need to have the Virtual Disk Development Kit registry key that was manually created during the installation of VDDK 1.1 deleted. Failure to do so will result in the VDDK 1.1 to still be utilized or fail if it has been uninstalled. (VDDK 1.1 does not support HotAdd mode on ESX 4.1)
When Change Block Tracking is unavailable backups will revert to 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. However, the amount of data transferred and stored by an incremental backup is limited to the changed blocks within the virtual disk. 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 these tools.
The Backup Job Summary report can show a detailed status of each virtual machine included in the backup. Follow the steps given below to include the status of protected virtual machines in the Job Summary Report:
Disk level backups can use allocated block tracking, which is part of VMware Changed Block Tracking (CBT). When enabled, allocated block tracking identifies portions of the virtual machine disk that have not been used, so those portions can be skipped during backup or restore.
Thin provisioned disk restores are supported only if allocated block tracking was used for the backup. Only source disks using lazy zero provisioning can be restored from thick provisioning to thin provisioning; disks using eager zero are always restored using thick provisioning.
If allocated block tracking was not active for the backup, the restore operation includes all of the blocks of the disk that were read during backup. This can result in thick provisioning for the restore, even if thin provisioning was requested.
The disk restore operation recovers all space that is reported in use (not zeroed out), so the VMDK can be larger than the size that was reported by the guest OS.
To restore ext4 files, or other Linux files that need to retain ACLs and permissions, restore the virtual machine disk (VMDK) to a new destination server and datastore, then ask your vCenter administrator to add the required files to the original VM or a test VM.
The original ACLs and permissions for the files are retained.
For VM backups, capacity licensing is based on the total backup size, calculated as the sum of backup sizes for all VM backup jobs after white spaces (blocks of zeros) are removed. The license counts the backup size of all configured subclients; virtual machines that are included in multiple subclients will be counted multiple times. The backup size is measured for usage tracking and shown on the Backup Job Summary Report.
The backup size can be different from the guest host size or used space value shown for the VM in the disk properties dialog by Microsoft Windows.
The following factors can affect the backup size calculation:
For example:
The backup size reflects the size after eliminating white spaces; but data that was written and deleted still counts as reserved (allocated) space. The layering effects of multiple virtual file systems can cause differences between the size reported by the guest host running within the VM and the reported backup size. Frequent deletion of large files can easily cause these numbers to be out of sync.
Version 9.0 reports on all allocated blocks in the VM. The amount reported for allocated blocks can be the same size or larger than what is actually in use and can contained reserved space for deleted items. For each VMware instance, Version 9.0 has an additional reporting column of the actual size of VMs.
The following measures can help reduce backup size: