Policy-Based Data Protection: Automate VM Backup and Replication in a Few Clicks

Virtualization is widely used by modern IT companies due to advantages such as scalability, rational consumption of resources, and convenient backup. Today’s blog post explains a new feature presented with NAKIVO Backup & Replication 8.1 that simplifies data protection management. The feature is called Policy-Based Data Protection and you can explore the working principle, purpose, and advantages of this feature by reading this blog post.

What Is Policy-Based Data Protection?

Policy-Based Data Protection is a feature that allows you to protect VMs matching policy rules. As you recall, you need to create a job when using NAKIVO Backup & Replication for protecting VMs by making backups, replicas, backup copies etc. You can add items matching the particular criteria to a job by using this feature – for example, consider adding VMs that contain “Linux” in their names that are in powered on state and are located in the specified storage area.

When Can It Be Used?

Policy-Based Data Protection can be used by companies that have dynamically changing virtual environments where VMs frequently migrate from one host to another or migrate between datastores. Here, some VMs can be deleted and new VMs can be deployed instead of deleted VMs, and VMs can change the networks to which they are connected, etc. This feature is especially useful for large environments with a high number of VMs that must be protected, in which manual management can be time consuming.

The Working Principle

Once a policy is created, all VMs that match the rules set by the policy are added to a job automatically. When some parameter is changed, a VM added to the job can be excluded and the new matching VM that was not added to the job before can be included. Imagine that you have a policy with the rule, according to which the VMs with the names starting with “Linux” must be added to a job. If a VM named LinuxUbuntu16 is renamed to Ubuntu16, the VM would be excluded from the current job. Inversely, if a VM named OpenSUSE is renamed to LinuxSUSE, then such VM would be added to the job automatically.

Similarly, if you have a policy-based job with a rule, according to which the VMs located on the datasore1 must be added to a job, then VMs located on other datastores will not be added to the job. If a VM located on the datastore1 is migrated to another datastore, then such VM will be excluded from the current job. Inversely, the VMs migrated to the datastore1 will be added to the job automatically.

You can also add multiple rules to a policy-based job. The maximum number of policy rules per job is 50. The limit of max source objects (such as VMs) is 500 for each job. If this number is exceeded, then a warning message is displayed: “The maximum number of job objects has been reached.”

There are two logical (AND / OR) conditions that can be used when you add multiple rules to a policy-based job.

If you need all rules to be matched, select the AND condition. This includes items to a job if all rules are matched.

If you require matching of a particular rule, select the OR condition. This includes items if any one rule is matched.

For example, you can create a policy with two rules to add VMs which contain names that start with “Linux” AND are located on the datastore1. Another case is creating a policy with two rules to add VMs which contain names that start with Linux OR which names start with FreeBSD for creating a job that would be used for Linux and FreeBSD virtual machines (the VMs must be named accordingly).

The inventory must be refreshed before changes in your virtual environment can be noticed by the product. The default auto refresh interval is 60 minutes. The minimal available inventory refresh interval is 5 minutes.

Selecting the policy view

A new policy view is available on the first step of a new job wizard and on the first step of edit job options. The policy view can be enabled in the drop-down menu where you can also select Hosts & Clusters or VMs & Templates view modes. Switching to a different view will reset your current selection. When you select the policy view, you are able to select a condition, a rule, a search option, and search criteria. Let’s explore search options and search criteria deeper.

Search Options

There are nine search options available for VMware jobs, eight search options for Hyper-V jobs, and eight options for Amazon EC2 jobs (see the table below). Each search option includes some search criteria that must consist of at least 3 characters. You should open the “Search by” dropdown menu to select a search option.

VMware Hyper-V Amazon EC2
1 VM name VM name Instance name
2 VM tag Instance tag
3 VM location VM location Instance location
4 Name of VM datastore VM path
5 Name of VM Network Name of VM Network Name of Subnet
6 Size of VM Size of VM Size of instance
7 Amount of VM RAM Amount of VM RAM Amount of instance RAM
8 Number of VM CPU Sockets Number of VM processors Number of instance virtual CPUs
9 VM power state VM power state Instance power state

Let’s review the policy job search options on an example of VMware jobs.

Creating a rule to search by a VM name

VM Name

The VM name search option is the first option on the list. Six parameters are available for this option.

Contains (is selected by default). The names of VMs contain the characters defined as the search criteria. For example, if you type ubuntu16 in the search criteria field, the VMs like these would be added to the job: full_ubuntu16, Ubuntu16.04, Xubuntu16, Xubuntu16-master. Search criteria for “Contains” and “Doesn’t contain” options are not case sensitive.

Creating a policy rule to search by a VM name that contains a search string

Doesn’t contain. Adds the VMs whose names do not contain the string defined as the search criteria. For example, you may need to add source VMs, but not VM-replicas to a job. Enter replica in the text field of the “Doesn’t contain” search criteria (If you use NAKIVO Backup & Replication, the -replica string is appended to the names of VM replicas by default).

Equals. You must enter the exact name of the VM that will be added to a job. The search criteria for this option is case-sensitive. If there is a VM named Xubuntu16 in your inventory, entering Xubuntu or xubuntu16 in the search criteria field won’t add the Xubuntu16 VM to the job. You must manually enter Xubuntu16 in this case because all characters must match.

Creating a policy rule to search by a VM name that equals search criteria

Doesn’t equal. The exact name of the VM must be entered manually as the search criteria, if you would like to prevent adding a particular VM to the job. For example, if you don’t want to add a VM that is named Win7-replica, you should enter Win7-replica in the text field of the search criteria. Entering -replica or win7-replica will not work in this case.

Starts with. This option is useful when you need to add VMs whose names start with the string defined as the search criteria. For example, if you enter Ubuntu in the text field of the search criteria, the VMs named Ubuntu Server 01, Ubuntu16.04 and Ubuntu18 will be added to a job. The VMs named full_ubuntu16 and Xubuntu16 will not be added to the job in this case. Search criteria for “Starts with” and “Ends with” options are case-sensitive.

Creating a policy rule to search by a VM name that starts with a value entered in the search string

Ends with. Adds the VMs whose names end with the string defined as search criteria. For example, if you want to add VMs with Linux operating systems of Ubuntu 16 family (Ubuntu, Kubuntu, Xubuntu) you may enter u16 in the text field of the search criteria. As a result, VMs named a_ubu16, full_ubuntu16 and Xubuntu16 will be added to the job.

Creating a policy rule to search by a VM name that ends with a value defined in the search string.

VM Tag

Tags allow you to attach metadata to VMs and other objects of your virtual infrastructure such as ESXi hosts, datacenters, clusters etc. and sort tags by categories. More than one tag can be assigned to a VM. Using tags is helpful for selecting VMs that are located on certain ESXi hosts but have a common purpose. You may assign VM tags to VMs that have no signs of their purpose in the VM names. Below you can see an example of creating tags for virtual machines:

  • Dev, Test, Prod – tags for VMs categorized by operation type.
  • Linux, Windows, FreeBSD, Solaris – tags for VMs categorized by the operating system type.
  • Backed up VMs, Replicated VMs, non-protected VMs – tags for VMs categorized by their protection level.

Viewing tags assigned to a VM in VMware vSphere Client

The VM tag option allows you to add VMs with the appropriate VM tag to the policy-based job. Let’s imagine that users of some department assign the “backed up VMs” tag to VMs which must be backed up. The tag is assigned to a VM when users create VMs or when VMs’ importance status is changed. The system administrator may not know whether a new VM of that department must be backed up, but he or she can create a policy-based backup job with NAKIVO Backup & Replication to automatically gather all VMs from that department (a datacenter in vSphere can use the name of the department) that have the “backed up VMs” tag to a single backup job.

Creating a policy rule to search items by VM tag

Search criteria for the “VM tag” option is not case-sensitive. The VM tag is not available for Hyper-V.

VM Location

Search by VM location allows you to add VMs located in the same datacenter, VM folder, host, or cluster to a job. VM location must be selected from the drop down menu where VMware, Hyper-V, or EC2 objects are displayed.

The logics of this rule has two options and is the following:

  • If the VM location is the defined parameter, then VMs that meet the condition are added to the job.
  • If the VM location is not the defined parameter, then VMs that are not located in the specified object are added to the job.

For VMware jobs, you can switch between Host & Clusters and VMs & Templates modes if you use the policy view when configuring a job. A rule that uses the VM location policy option can be useful in a combination with other rules.

Using search by VM location for a policy-based backup job.

Name of VM Datastore

This option allows you to select VMs that are located or not located on the datastores specified by the policy.

These are the following search parameters for searching VMs by the name of VM datastore:

  • Contains
  • Doesn’t contain
  • Equals
  • Doesn’t equal
  • Starts with
  • Ends with

The logics of using these parameters is similar to the logics of using said parameters for the VM name option. The difference is that the search criteria are used for specifying the datastore name instead of VM name. VMs located on multiple datastores can be selected by using the Name of datastore policy option. This option is not available for Amazon EC2 jobs.

Example. Imagine that you have three ESXi hosts – ESXi1, ESXi2 and ESXi3. Each host has two datastores that are named according to the host names and disk types. The datastores’ names are ESXi1-HDD, ESXi1-SSD, ESXi2-HDD, ESXi2-SSD, ESXi3-HDD, ESXi3-SSD. You have a free hour for lunch and should schedule backup of VMs located on SSD datastores for all hosts between 1:00 and 2:00 PM. Backing up VMs located on HDD-based datastores requires more time (due to the larger amount of data stored on HDD-based datastores) and, for this reason, you want to backup that VMs at night during non-working hours. You should create two policy-based backup jobs.

Job1. Rule1. Search by the name of VM datastores that contains the SSD string in the text field of search criteria. Schedule starting the job at 1:00 PM and ending at 2:00 PM for working days.

Job2. Rule1. Search by the name of VM datastores that contains the HDD string in the text field of search criteria. Schedule starting the job at 8:00 PM for working days.

Using search by the name of VM datastore for configuring a policy-based backup job

Name of VM Network

With this policy option, you can select all VMs that are connected to virtual networks specified by the policy. You can read more about virtual networks and virtual switches in the blog post.

Search parameters are the same as the search parameters of the Name of VM datastore policy option:

  • Contains
  • Doesn’t contain
  • Equals
  • Doesn’t equal
  • Starts with
  • Ends with

Logics of using these search parameters is also similar. Let’s explain an example, when this policy option can be used.

Example. A VM can have multiple virtual network adapters and each of them can be connected to a different network. A VM can be connected to the internal and external networks; to the test or production network. Imagine that you want to back up VMs connected to the production network that is named VM Network 2 (the VMs are running on different ESXi hosts). For making this, you need to create a policy-based backup job, and add a rule that can search by the name of the VM network that equals VM Network 2.

Using search by the name of VM network for configuring a policy-based backup job.

Size of VM

This policy option allows you to search VMs by the size of a particular VM if the size of VM:

  • Is more than [search criteria] [units]
  • Is less than [search criteria] [units]
  • Equals [search criteria] [units]
  • Does not equal [search criteria] [units]

The search criteria must be only digital (at least one digit). Units can be Megabytes (MB), Gigabytes (GB), Terabytes (TB) and can be selected from the drop down menu.

The Size of VM policy option can be useful for replication. You may need to replicate small VMs to the small datastores on ESXi servers as well as replicate large VMs to large datastores. For example, you should replicate VMs whose size is less than 4 GB to the datastore1 whose size is 1 TB, while the VMs whose size is more than 4 GB would be replicated to the 10TB datastore2. You may also need to select VMs that, for example, consume more than 24 GB and less than 30 GB of disk space.

Using search by the size of a VM for configuring a policy-based replication job.

Amount of VM RAM

This policy option allows you to add the VMs with the appropriate amount of VM memory to a job. VMs are added to the job if amount of VM RAM:

  • Is more than [search criteria] [units]
  • Is less than [search criteria] [units]
  • Equals [search criteria] [units]
  • Does not equal [search criteria] [units]

You must enter at least one digit to the search criteria field. Units can be MB or GB and can be selected from the drop down menu.

The Amount of VM RAM policy option can be useful for replication jobs. For example, you have a limited amount of RAM on an ESXi host deployed on a disaster recovery site. This host doesn’t have enough memory to run memory-hungry VM replicas after a failover. You can create a policy-based replication job and replicate VMs whose amount of VM RAM is less than 4 GB to that ESXi host. VMs that consume more RAM can be replicated to another powerful ESXi host with another policy-based replication job.

Using search by amount of VM RAM for configuring a policy-based replication job.

Number of VM CPU Sockets

This policy option allows you to add the VMs with the appropriate number of CPU sockets to a job. VMs are added to the job if the number of VM CPU sockets:

  • Is more than [search criteria]
  • Is less than [search criteria]
  • Equals [search criteria]
  • Does not equal [search criteria]

Search criteria is the number that must consist of at least one digit.

The Number of VM CPU sockets policy option can be useful for replication jobs similarly as the Amount of VM RAM policy option.

Using search by the number of VM CPU sockets for configuring a policy-based replication job.

VM Power State

Using this policy option, VMs can be added to a job depending on their power state that is (or is not):

  • Powered On (Running)
  • Powered Off (Off/Stopped)
  • Suspended (Saved)

Using search by the VM state for configuring a policy-based replication job

Let’s see the use cases.

Example 1. Imagine that you want to back up VMs with the enabled VMware Changed Block Tracking feature. VMware Changed Block Tracking can be used only for backing up (replicating) the VMs that are in the Powered On state. In this case you can create a policy-based job for automatic adding of the powered-on VMs to the job.

Example 2. You need to back up VMs with some applications that are not supported by application-aware VM backup. Hence, VMs with such applications should be powered off to ensure data and application consistency. In this case, you can create a policy-based VM backup job and configure automatic adding of the powered-off VMs to that job.

Configuration Examples with Multiple Rules

You can create different combinations of rules in policy-based jobs. Let’s see some examples of policies with multiple rules for VMware VMs.

Example 1. You need to back up Ubuntu-like Linux VMs that are stored on SSD datastores and are powered off. You know that the names of your VMs contain the name of the OS and that the names of your datastores contain the disk type. Create a policy-based VMware backup job, select the Include items if ALL rules are matched condition and add three rules.

Rule 1. Search by: VM name contains ubuntu.

Rule 2. Search by: Name of VM datastore contains ssd.

Rule 3. Search by: VM power state is Powered Off.

Configuring a policy-based backup job with three rules

Example 2. You need to back up all VMs with Windows 7 and Windows Server 2016 operating systems installed. You know that the names of your VMs contain a part of the OS name. Create a policy-based VMware backup job, select the Include items if ANY rule is matched condition and add rules as following.

Rule 1. Search by: VM name contains win7.

Rule 2. Search by: VM name contains srv2016.

Rule 3. Search by: VM name contains server2016.

Configuring a policy-based backup job with three rules by using the OR condition

Example 3. You need to back up VMs from the QA datacenter with Red Hat Enterprise Linux installed (you know that that VMs contain RHEL in their names). Create a policy-based VMware backup job, select the Include items if ALL rules are matched condition, and add rules as following.

Rule 1. Search by: VM location is [VM & Templates] QA.

Rule 2. Search by: VM name contains rhel.

Rule 3. Search by: VM name does not contain replica.

 Configuring a policy-based backup job with three rules – location, name, name

Advantages of Using Policies

As you can see, policy-based data protection provides you with more possibilities for configuring jobs in NAKIVO Backup & Replication. The main advantages of using policy-based jobs are:

  • Time saving. Manual VM management is time consuming for large virtual infrastructures. Manual searching of the VMs for adding them to a job requires significant human attention and time. Policies allow you to simplify configuring VM protection jobs. You can save time when you need to add multiple objects that have different locations, but have some common criteria such as a VM name, datastore name, host name, power state, size of VM, etc.
  • Automation. Some items may go unnoticed and, as a result, can be missed when they are added manually. You can avoid adding VMs to a job manually since with policies, you can set conditions and search criteria for adding the matching items to the job automatically.
  • Flexibility. You can use different approaches that are suitable for an environment that is dynamically changing for adding items to a job. When new VMs are frequently added, you don’t need to manually update the existing job, just wait for updates of the inventory, and matching items will be added automatically.

Conclusion

Policy-Based Data Protection is a useful feature that is now available in NAKIVO Backup & Replication 8.1 and can be used for VMware, Hyper-V, and Amazon EC2 data protection jobs. This feature is especially useful for large, dynamically changing environments, also providing greater simplicity, flexibility, time saving and automation. The policy view can be selected on the first step of configuring a job. In combination with other great features provided by NAKIVO Backup & Replication, you get a powerful all-in-one data protection solution for your virtualized or cloud environment.

Policy-Based Data Protection: Automate VM Backup and Replication in a Few Clicks
Rate this post

Share: