You can restore full VMs, VMDK files, or guest files and folders. You can also restore a disk and attach it to another VM.
Restores with Changed Block Tracking (CBT) Using Backup Copy
Changed Block Tracking (CBT) is a VMware feature that enables efficient backup of virtual machines by tracking changes and only backing up changes rather than complete virtual machines. CBT is used automatically for restoring a full virtual machine when the Restore in place and Unconditionally overwrite VM with the same name restore options are used, and if restored changes total 50 MB or more.
Since only changed blocks are restored, a CBT restore is much faster and more efficient than a classic restore. If a CBT restore cannot be performed or if the restore job is restarted, the restore reverts to a classic restore.
CBT restores are enabled by default; but you can disable them as described in Disabling Restores Using Changed Block Tracking.
To initiate a CBT restore, perform the steps in Overwrite Virtual Machines with the Same Names.
Notes
-
CBT restores are supported for virtual machines using hardware version 7 or higher.
-
For IntelliSnap, CBT restores are only supported when restoring from a backup copy; it is not supported when restoring from an IntelliSnap backup.
-
CBT restores are not supported for attaching a disk to an existing virtual machine.
-
Only the first restore from a backup can use CBT. To perform another CBT restore, another backup must be performed first.
-
If you perform an incremental backup after performing a CBT restore, the incremental backup uses the changed block tracking IDs from the last backup that ran before the restore; the query of changed sectors fails and the CBT status is set to Failed in the CommCell Console.
-
You can ignore the CBT status; new changed block tracking IDs are generated and can be used for the next incremental backup job or for CBT restores.
Disk Provisioning
When performing a restore of a full virtual machine or attaching VM disks to an existing virtual machine, you can change the disk provisioning on the Restore Options for All Selected Items dialog. The following disk provisioning types are available:
-
Original: (default) Use the same disk provisioning that the source virtual machine used at the time of backup.
-
Thick Lazy Zero: Use thick lazy zero provisioning to allocate disk space for all disks. This method only writes to sectors of the disk that contain data.
When this option is used to restore a thick eager zero disk, empty extents are written. In the vSphere client, the resulting restored disk will still be displayed as a thick eager zero disk.
-
Thick Eager Zero: Use thick eager zero provisioning to allocate disk space for all disks. This method writes zeros to any unused sectors of the disk.
If the original source disk was provisioned as thin or thick eager zero, a restore that specifies thick eager zero provisioning can skip any empty sectors of the disk, because the empty sectors are already written with zeros. In this case, restore logs may indicate that the disk provisioning method was thick lazy zero.
When restoring from a thick lazy zero disk using thick eager zero provisioning, zeros are written to all empty sectors.
-
Thin: Use thin provisioning to allocate disk space for all disks in the virtual machine.
When you restore a virtual machine that has thin disks on a NFS datastore, empty blocks on the disk are not restored; only the actual data on the disk is restored.
If Change Block Tracking was not functioning properly at the time of backup, disk data is still restored and empty blocks are not restored. As a result, disks are restored with the correct data size and the restore operation takes considerably less time.
Transport Modes
The following transport modes can be selected on the Restore Options for All Selected Items dialog:
-
Auto: (default) The most suitable transport is selected automatically based on the setup.
-
SAN: For directly connected storage using Fibre Channel (FC) or Internet SCSI (iSCSI) protocols; only available if the proxy is on a physical machine.
-
HotAdd: Used when the Virtual Server Agent is installed on a virtual machine on an ESX server.
-
NBD: Data is transmitted over a TCP/IP connection between the ESX server and proxy.
-
NBD SSL: Uses the TCP/IP connection with encrypted data transfer.
-
NAS: NAS (network attached storage) transport mode enables the virtual server agent (VSA) proxy computer to read data directly from the network file server (NFS), without going through an ESX host or transferring data over the local area network (LAN).
Notes
In most scenarios, restores using SAN and HotAdd transport are faster than NBD or NBD SSL operations; but SAN restores using thin disk provisioning can be slower than LAN restores. Performance can be improved by using NBD for thin disk provisioning, or by setting the transport mode to SAN and specifying thick eager zero disk provisioning.
VSA proxies must have access to NFS exports from the NFS Server.
ESX proxyless backups (without proxy ESXi host in backup copy operation) with explicit selection of NAS mode is supported only for NetApp.
For other NFS storage vendors, the hardware snapshot datastore is mounted to a proxy ESX server, and therefore, will use the NAS transport mode during backup operations.
Live Browse for IntelliSnap uses NBD transport mode.