Hitachi Data Instance Director (HDID) made some significant improvements to it's VMware support back in May 2018 with its 6.5 release, over a few of these blog posts I'll try to go though each piece in some detail to explain what it does, how it behaves and how it can be used.
In this blog I'll talk about the different selection criteria available and what actually happens under the hood. I'm going to assume that there is already at least one VMware application node has been created in HDID.
Create the Policy
First off we need to create a Policy using the Hypervisor classification
Once we've given our Policy a name, we can progress to choosing a VMware application node to select from and we're presented with this screen
Here we can add and remove resources to include and exclude from our backup Policy.
Clicking add leads us a choice about our selection methods
The two options here work in very different ways when being processed by HDID.
HDID will attempt to resolve all selections down to Virtual Machines contained within those selections. This means that selecting an empty Datastore, for instance, will result in a HDID error of "There are no VMs to backup".
Browse for Resources
This selection allows browsing of the VMware node chosen and allows selection of any existing objects within VMware
This method records the Managed Object Reference (MOR) in the Policy and will use it to find the selected objects in the given VMware node.
The MOR uniquely identifies a VMware object, regardless of changes to that object (rename, moving folder etc). If the object is deleted and recreated, however, it will be assigned a different MOR by VMware and may no longer be included in the Policy.
To this end, selecting VMware container objects such as Folders, Datastores, Hosts or even whole Datacenters is safer than selecting individual Virtual Machines, as HDID will resolve the container object and protect everything beneath it. If the container no longer exists then the resolution will fail.
Tags are the exception here as they are resolved by name. As long as the tag exists within VMware it can be browsed, it does not have to be assigned to any VMware resources.
Using tags in VMware and in HDID Policies allows for a very simple backup configurations to support various service level agreements for data protection.
The main issue with tags is that they do not belong to the resource, they only exist within the vCenter. This can cause issues when using tools such as SRM as the tags will not be replicated to the secondary vCenter.
Specify Resource by Name or Wildcard
This selection allows the VMware resources to be selected by name either explicitly or by a wildcard
This method records the resource type (Datacenter, Host, Folder and so on) and the given pattern and will search VMware for matching entities every time the backup is triggered. It does not incorporate hierarchies into the matching, and so allows for named resources conforming to a pattern to be distributed via different Hosts, Folders and Datastores within the VMware environment to be protected.
Whilst selecting by wildcard is very flexible, it is very easy to rename a resource such that it no longer conforms to the pattern, and therefore will not be included in the backup.
Includes and Excludes
Returning to the classification screen once again and using the available selections we can see that building an accurate backup Policy to protect your VMware environment can be achieved in numerous ways, regardless of how the VMware resources are organised.
Next time we'll talk about the differences between VADP protection and Hardware protection as well as covering what Virtual Machines can be protected and which ones cannot.