Agentless VMware Restore Job Operations

The following table summarizes conditions associated with the different types of restore operations:

Restore Operation	Restore Source (Backup Type)	Restore Target	Catalogic DPX Required on Restore Target	Restore Requires iSCSI Initiator Enabled on Host	Restore Requires iSCSI Initiator Enabled on VM	Storage Relocation Used
Instant VM Restore	Agentless VMware Backup snapshot	ESXi or vCenter	No	Yes	No	No
Full VM Restore	Agentless VMware Backup snapshot	ESXi Server	No	Yes	No	Yes, in most cases, otherwise cloning is used.
Instant VMDK Restore	Agentless VMware Backup snapshot	VM	No	Yes	No	No
Full VMDK Restore	Agentless VMware Backup snapshot	VM	No	Yes	No	Yes, in most cases, otherwise cloning is used.

Storage Relocation vs. Cloning

In the context of Full Restores, storage relocation, and cloning are two distinct processes. Storage relocation allows immediate access to restored disks once RDM disks are connected to the VM. This is typically the preferred method for full VM and VMDK restores in Agentless VMware Backup.

On the other hand, cloning requires waiting until the full restore process finishes before the disks are usable. Cloning becomes necessary when:

• The target VM is powered off.

• Any target datastore is NFS (only original location restores are supported for NFS).

Instant VM Restore

Instant VM Restore uses iSCSI LUN mapping to quickly restore a VM to the original or an alternate VMware ESXi or vCenter. A snapshot stored on the backup storage system is mapped to the VMware ESXi host that you specify as the restore destination. This method does not physically transfer data, requiring minimal space in the datastore.

Changes made to the mapped drive do not affect the snapshot. The restored disk is attached as an RDM LUN in virtual compatibility mode.

Tip. If a VM of the same name already exists at the restore destination, the restore job fails. You must delete or rename the VM on the target host before rerunning the restore.

Full VM Restore

Full VM Restore restores a VM to the original or an alternate location, creating a flat VMDK file on the target datastore for each restored disk. In most cases, Full VM Restore uses temporary iSCSI mapping of the restored disks as RDMs to the target VM.

This allows the restored VM to be used immediately, while storage relocation transfers data in the background. Again, if a VM of the same name already exists at the restore destination, the restore job fails. You must delete or rename the VM on the target host before rerunning the restore.

Instant VMDK Restore

Instant VMDK Restore uses iSCSI LUN mapping to restore a selected VMDK file from an Agentless VMware Backup snapshot to an original or alternate VM. This method is similar to Instant VM Restore, but it restores a VMDK rather than an entire VM. To restore multiple VMDKs on a VM, repeat the restore for each VMDK.

When restoring a VMDK, Catalogic DPX creates a temporary LUN on the back destination NetApp storage system hosting the backup, maps the LUN to the target host, and then attaches the LUN to the target VM as an RDM disk in virtual compatibility mode. A separate mapped LUN is used to create a temporary VMFS datastore, which contains attached RDM disks. The temporary datastore is created automatically by Agentless VMware Backup.

Full VMDK Restore

Full VMDK Restore restores a VMDK file to a VM from an Agentless VMware Backup snapshot. This method is similar to Full VM Restore, but it restores a VMDK rather than an entire VM. To restore multiple VMDKs on a VM, repeat the restore for each VMDK.

A temporary datastore is created to contain RDM disks. However, in the case of a Full restore, the temporary datastore is deleted after the restore completes.

This method first performs an Instant restore internally, with a LUN-attached VMDK. When the Instant restore completes, storage relocation is used to convert the attached LUN to a flat format VMDK on a production datastore.

Storage relocation, enabling immediate access to the restored VM, is used in most cases.