How to create VM restore points using host based backups

It is assumed that the following tasks have been performed:

The Protector Master software has been installed and licensed on a dedicated node.
The Protector Client software has been installed on the node that will act as the proxy for the vCenter or ESX/ESXi host.
If the vCenter proxy and destination are on separate nodes, the Protector Client software must also be installed on the proxy where the destination will reside.
Permissions have been granted to enable the Protector UI, required activities and participating nodes to be accessed. In this example all nodes will be left in the default resource group, so there is no need to allocate nodes to user defined resource groups.
A VMware user has been created that provides the required privileges as detailed in VMware user privileges. This user will be required when creating the VMware proxy node in the steps that follow.

Note:

Ops Center Protector will attempt to enable Changed Block Tracking (CBT) if it is not already enabled on any virtual machines to be backed up. If the virtual machine does not have CBT enabled or Ops Center Protector fails to enable it, then the entire VM is backed up instead of just the changed blocks. Instructions to manually enable CBT can be found on the VMware knowledgebase (http://kb.vmware.com/selfservice).

This task describes the steps to follow when creating recovery points for VMs in a repository. The data flow and policy are as follows:

Figure. VMware Batch Backup Data Flow to a Repository

Note: It is only possible to specify a batch mover when defining a data flow from a vCenter or ESX/ESXi host.

Table. VMware Backup Policy
Classification Type	Parameters	Value
VMware	VMware Node	myVMwareHost
VMware	Include Items	Refer to About VMware policy classifications for details on how to specify VMs that are to be included in a backup.

Operation Type	Parameters	Value	Assigned Nodes
Backup	Run Options	Run on RPO	Repository Amazon S3 Hitachi Content Platform (HCP)
	RPO	1 hours
	Retention	1 day

Locate the source and destination OS Host nodes in the Nodes Inventory and check that they are authorized and online.
If you are following best practice, this node will be used both as the proxy for the VMware source node and also as the proxy for the destination node. It is identified as the Proxy Node when creating nodes in the following steps.
Create a new VMware node (unless a suitable one already exists) using the VMware Node Wizard.
The VMware node type is grouped under Hypervisor in the Node Type Wizard.
1. Specify the Host name or IP Address of vCenter/ESXi Server.
2. Specify the Username and Password of a user having the required privileges as detailed in VMware user privileges.
3. Check that this node is shown as authorized and online.
Create a new destination node, for example a Repository, using the Repository Storage Node Wizard and check that it is authorized and online.
The destination nodes, like the Repository node are grouped under Storage in the Node Type Wizard. You can direct data from multiple nodes to a single repository so there is no need to create a new repository if a suitable one already exists.
If a new Repository node is being created please the default Generation 2 type.
Define a policy as shown in the table above using the Policy Wizard, VMware Classification Wizard and Backup Operation Wizard.
The VMware classification is grouped under Hypervisor in the Policy Wizard.
Draw a data flow as shown in the figure above, that shows the VMware source node connected to the Repository destination node via a Batch mover, using the Data Flow Wizard.
Assign the VMware-Backup policy to the VMware source node and the Backup operation to the Repository destination node on the data flow.
Select the Standard Store Template if assigning the operation to a Generation 1.
Compile and activate the data flow, checking carefully that there are no errors.

Note: The Rules Compiler will generate a Warning 10209. This is expected behaviour because repositories cannot perform auto-validation on VMware data. The repository's VMDK backups are built by creating an initial full backup and then capturing changed blocks, so there is nothing meaningful that the repository can verify. The warning can be suppressed by using a Repository Store Template with Automatic Validation set to Never in the Destination Template Wizard.
It is OK to activate these rules despite the warning, since the Automatic Validation option is ignored for VMware backups.
Locate the active data flow in the Monitor Inventory and open its Monitor Details.
The policy will be invoked automatically to create an initial backup and then repeatedly according to the RPO specified in the policy. The policy can also be manually triggered from the source node in the monitor data flow.
Watch the active data flow via the Monitor Details to ensure the policy is operating as expected.
You should periodically see:
- Backup jobs appearing in the Jobs area below the data flow that cycle through stages and ending in Progress - Completed.
  Tip: If CBT is working correctly, the resynchronization progress will show the sending of the entirety of the virtual machines’ disks, however, the synchronization will complete after it has transferred the changed parts of the disks. If CBT is not working correctly, the entire disk will be transferred.
  For example, in an initial synchronization the VMware server appears to be sending the complete 24 GB virtual disk, however, the synchronization will complete after approximately 7 GB has been sent; this is the used space on the virtual disk.
  There is a detail level log that gives the actual amount transferred once the synchronization is complete.
  After the initial synchronization is complete, subsequent backups will only transfer the changed blocks from the previous backup. Each backup however will be, in effect, a full back up so when performing a restore just the one restore operation is required.
- Information messages appearing in the Logs area below the data flow indicating rules activation, backup and resynchronization events.
Review the status of the Repository to ensure backup snapshots are being created.
New snapshots will appear in the repository periodically as dictated by the RPO of the policy. Old snapshots will be removed periodically as dictated by the Retention Period of the policy. The retention period of individual snapshots can be modified here if required.