Using Veeam and VMware vSphere tags for …docs.media.bitpipe.com › io_12x › io_128788 ›...

Using Veeam and VMware vSphere tags for advancedpolicy-drivendata protectionLuca Dell’Oca vExpert, VCAP-DCD, CISSP

Using Veeam and VMware vSphere tags for advanced policy-driven data protection

2© 2015 Veeam Software

Contents1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Setting the stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.3 The three steps towards a policy-driven data protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

3. Step 1: Define a “desired state” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Leveraging vSphere tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.2 How to apply tags to virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

3.2.1 Apply tags manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

3.2.2 Apply tags using automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.3 Tagging using Veeam ONE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4. Step 2: Create the rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Tags creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 The “No Backup” tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5. Step 3: Apply the rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Jobs based on tags

in Veeam Backup & Replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2 Dealing with backup files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6. Restores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.1 Configure roles and scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.2 Self restore portal for application owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7. An integrated approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.1 Performance growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.2 Protect the production environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

About Veeam Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25



1. IntroductionModern data centers are becoming more and more complex, and there are several reasons for this trend.

First, there is a business reason behind any technical enhancement, and lately the paramount business

requirement is to shrink as much as possible (the so called “time to market”). People have become

used to the quick deploy time provided by virtualization – reducing provision times from weeks and

months to days or hours. This has led to the more general concept that any new workload should be

immediately available upon request. Cloud-like technologies have further pushed this concept by

adding additional elements to the data center such as “infinite scalability” and “self-service.”

Infinite scalability is more of a perception than a real situation. Beneath different and always

increasing layers of abstraction, there is always a physical infrastructure, and regardless of all the

provisioning enhancements that latest technologies have allowed (for example hyperconvergence),

a system cannot scale infinitely and in a short period of time. What this concept means is that the

“perception” of a user’s “cloud-like” platform is that it is a system that can scale without any apparent

limit, regardless of the amount of resources requested.

The second concept is “self-service.” Once there’s an “infinitely scalable platform” to be consumed, a

consumer should not be forced to follow a strict provisioning process. This has been used in the past

by infrastructure managers with the guarantee of respecting the defined standards and maintaining a

tight control on the finite resource to be sure that no additional request could exhaust those resources.

But if the underlying platform can scale without (apparent) limits, the user could be easily and safely

entitled to consume additional resources without asking for them in advance.

Still, some sort of governance needs to be implemented. Workloads should be configured as defined

by IT administrators, regardless of who is deploying them. Antivirus, monitoring, backup, patching,

every new workload needs to have all the same characteristics of the other ones.

But the complexity and growth of these data centers have made manual control of these parameters

basically impossible, or at least highly inefficient and prone to errors. If there are thousands of virtual

machines, it’s pretty certain some of them will be skipped during a patching cycle, some will not be

added to the monitoring platform, or they will never be backed up.

This scenario has lead infrastructure administrators to introduce control and management mechanisms

to their data centers to cope with the “new way” of consuming resources.

First, better and more effective monitoring and capacity planning. Offering on the frontend infinite

scalability and self-service, means the backend needs to be carefully designed, planned to scale from

the beginning to avoid dangerous forklift upgrades, and most of all, monitored so that administrators

can spot in advance trends in resource consumptions and decide for the acquisition and deployment

of additional resources in time.



Second, automation and policy-based management. The need for complete and absolute consistency

of a large environment can only be solved via the so called “desired-state” configuration. Instead of

applying configurations manually to guarantee that each virtual machine and application is configured

as desired, a preferred solution is to have an automation platform that can (automatically) check

each workload against a desired configuration, and in case of a drift, go and correct it. Thanks to this,

administrators can rest assured that each parameter will be configured as they want.

From a data protection perspective, this also helps avoid what I like to call “policy-based anarchy.” With

just policies and self-service, an environment is not completely manageable, and complete freedom

can lead to anarchy.

Let me explain this concept: Policies are a great solution to guarantee consistency, and thanks to self-

service, an administrator can let his users/customers decide which policy is better for their workloads.

Being the application owners, they probably know better than anyone which policy is best.

Let’s use a quick example: A data protection plan may offer different RTO values to users, like 24 hours

(one backup per day), but also 12h or 4h for more critical workloads. These policies, however, have a

cost associated with them: The more retention points needed, the more space on a backup device

to be consumed. Also, running data protection activities during working hours (like it’s needed when

selecting the 4h policy) would lead to additional load and pressure on the production environment

that now has to consume resources at the same time to run the workloads and to feed the data

protection solution with data to be saved.

If users have complete freedom to decide which policy to apply to their workloads, the result may be a

depletion of the available resources, both in terms of the data protection solution not able to complete

the tasks needed to protect workloads frequently, but also the production environments may suffer.

For example, the production storage at some point may not have enough storage power to serve the

running workloads and all the read activities happening during the backups.

For these reasons, policies should be carefully planned by administrators and offered as a catalog

where users can choose from. Additionally, some sort of “showback” if not “chargeback,” should be

implemented to make users aware of the consequences in terms of IT resources consumption, and

ultimately drive them to better decisions. Users could also create a sort of internal service provider

where the IT department can ask for an additional budget to be provided by other lines of business if

they require additional performances from the data protection solution in use.

In addition, the chosen data protection solution should be able to offer at the same time a policy-based

framework and technologies to better integrate with the production environment and guarantee

service level agreements while operating. Long gone are the days where the “backup administrators”

cared just about their operations in a siloed environment. In a modern data center, where all the

components are integrated with each other, every decision made at the data protection level has a

consequence on other different components.

Veeam® Backup & Replication™ v8, part of Veeam Availability Suite™, is perfectly suited for such

environments thanks to its advanced capabilities.



First of all, the scale-out capabilities. Using the same installation and simply adding more processing units

(called “proxies”), Veeam can scale to protect large environments without suffering a degradation of its

performances, and without requiring a painful forklift upgrade to move to a bigger version of the solution.

Customers can pick the best-suited hardware to execute Veeam components, such as proxies or

repositories. For example, a mix of fast storage arrays backed by SSD and HDD can offer a landing area

for recent backups that can be stored and restored at the maximum speed. Additional areas using

deduplicated appliances or tapes can lower the price per GB of a secondary location where data needs

to have a longer retention at a better price.

However, as previously stated, the data protection solution must not be a silo. On the contrary, it has to

integrate with the production environment. That’s where some of the Veeam technologies comes into play.

The support for major vendor’s storage snapshots allow backups to complete with a much lower

impact on the production storage and virtualized environment. Backups can now be executed during

production hours without impacting production workloads.

Backup I/O Control (patented) can monitor storage latency in real-time, and be able to throttle

backup speeds so that storage latency will never raise above the defined limits. Modern data centers

are moving toward an Always-On Business™, where less maintenance/backup windows will be

available. Being able to run backups in the middle of production hours without damaging the needed

performance of a workload is a value that customer cannot ignore.

Finally, the topic of this paper: Policy-driven data protection. Thanks to the support for vSphere tags,

administrators can define activities that will protect workloads based on the “desired state” that their

users will define for their workloads. Instead of manually selecting virtual machines to be added to

given backup jobs, with all the risks of missing or violating a requested policy, administrators can

preemptively define backup policies, and let the software apply these policies to virtual machine.

Administrators can rest assured that no workload will be forgotten or protected by the wrong policy.

In this paper, you will learn how to apply these concepts to your environment using Veeam.



2. Setting the stage

2.1 AudienceThis document is intended for use by individuals working in companies using VMware vSphere

environments protected by Veeam Availability Suite v8 (or Veeam Backup & Replication v8), and willing

to increase their levels of automation and move towards a policy-driven Availability. Regardless of their

roles, being it architects, administrators, virtualization specialists, storage or network managers, and

data protection admins, this document is a useful source of information for learning how it’s possible to

leverage the automation capabilities of the involved software components.

2.2 ScopeThis document describes a scenario involving a VMware vSphere 6.0 virtualized environment and

Veeam Backup & Replication v8 (as a stand-alone deployment or as part of Veeam Availability Suite

v8). Depending on your business or technology needs, some suggestions may require changes to be

applied, and each environment should be carefully evaluated against the official documentation of the

involved software solutions mentioned in this document.

Deployment, installation and initial configuration of the different software solutions will not be covered

in this document; readers are expected to have basic knowledge of each software. When and if needed,

additional information should be gathered from different official documentations.

This document has been developed on, and the suggested solutions have been tested against:

Veeam Backup & Replication v8 Update 2b (build 8.0.0.2030)

VMware vCenter 6.0 (build 2656760)

VMware ESXi 6.0 Express Patch 2 (build 2715440)

2.3 The three steps towards a policy-driven data protectionNo system is born with inner policies, especially existing systems where old ways of doing data

protection need to be transformed and updated. It’s more of a journey, where an environment can (and

should, in my opinion) be migrated towards this “new” way of dealing with Availability. After I explained

in the introduction why you should have a solution based on policies rather than manual jobs, let’s see

the common steps that this journey involve.



3. Step 1: Define a “desired state”The desired state is the state of the object where all the requested conditions are met. One or multiple

parameters are set, each of them has different possible values, and the combinations of all the values

gives the final desired state.

In terms of Availability, when talking about virtual machines (VMs), the desired state can be a

combination of:

• RPO = How frequently a VM has to be protected (either via backup or replication)

• Application quiescence = Needed YES or NO?

• Encryption = Does the backup set need to be encrypted

• Remote replication = Does the VM need to be replicated into a secondary location?

And so on. Each possible parameter available in Veeam Backup & Replication can be part of the desired state.

The interesting part, however, of the Desired State, is not how it is built, but rather who’s in charge of its

definition. These parameters are derived from a backup job for example, but in the case of a policy-driven

solution, it’s not the Backup Administrator to define those parameters, it’s the Application Owner.

This is an interesting shift from the past, where people in charge of data protection at the time were the

managers and consumers of their solutions. Here, we are talking about an Application Owner that defines

the configurations he wants, and then another subject that is only responsible for applying them.

Application Owners are in charge of defining desired states because they have designed and deployed

their own applications, and thus they do know the requirements they have in terms of Availability. A

database administrator probably knows better than the Veeam administrators the required parameters

for the successful protection of his own databases.

The ultimate goal of this type of solution is to offer self-service at any stage of the Availability life cycle,

from the very first step of defining the requirements for each workload that has to be protected.



3.1 Leveraging vSphere tagsIn a VMware vSphere environment, the easiest and most powerful way to allow application owners to define

their own required state is by using tags. First introduced in vSphere 5.5, the release of vSphere 6 tags are

now fully consumable via proper API from external components such as Veeam Backup & Replication.

In IT, a tag is a non-hierarchical keyword. This kind of metadata helps describe an item and allow it to

be found again by browsing or searching. Tags are generally chosen informally and personally by the

item's creator or by its viewer, depending on the system.

In vSphere, any user with sufficient permissions can tag any object that is available in his console. For

the purpose of this document, we will refer to tags applied to virtual machines, but keep in mind tags

can be applied to datastores, networks, folders, resource pools, and so on.

There are many advantages of tags compared to other classification systems:

• Any object can have multiple tags. For example, a VM can be tagged as being a production VM or a

development VM, or both, while for example when using more rigid solutions like folders, a VM can

only belong to a single folder at a certain point in time

• Tags can be applied by users at any time, while constructs like folders again are usually created and

consumed by administrators

• Searches and filtering can be done using tags, both in single mode or using boolean operators. This

gives powerful search capabilities for solutions leveraging tags

• Finally, a tag is immediate. After assigning a VM, a native property of the VM itself, the tag sticks to this

VM until it’s removed. It’s not a property of the Availability solution in this case. A single VM can have at

the same time tags describing the desired state of Availability, but also tags used for the identification

of the department using the VM, the Operating System, the running application, and so on

For all these reasons, Veeam customers looking for a powerful, policy-driven solution should leverage

vSphere tags to described the desired state of their virtual machines.



3.2 How to apply tags to virtual machinesThere are different ways to apply tags to virtual machines. Let’s take a look at the options.

3.2.1 Apply tags manually

The first and most accessible way to apply tags is to use the vSphere Web Client. From the page of an

object, it’s easy to apply tags:

Fig. 1: Apply tags to a virtual machine from vSphere Web Client



The “Assign” link opens the “Assign tags” wizard, where a user can assign a VM one or more existing tags,

or if it has permissions for it, create a new one.

Fig. 2: Assign tags to a virtual machine in vSphere Web Client

One of the issues that may arise by using this method is the slowness of the process. Each VM needs

to be manually tagged, and when the environment becomes too big, the time it takes can be too

much. This problem can be minimized to a certain degree because in a multi-tenant environment, each

department has to manage tagging only for their own VMs and not all of them. Nevertheless, the effort

may still be considerable.

The other issue that may arise with manual tagging is related to errors, as in any manual process.

3.2.2 Apply tags using automation

When tagging procedures need to be applied to a large environment, the best solution is to involve

automation. Automation applied to IT tasks brings many advantages, and people thinking about

introducing policy-based solutions should really look into this.

First, automation brings accuracy. Once a procedure is defined into the automation solution, it can be

replicated an infinite number of times with the same exact steps, removing any human error. This is

paramount when managing a multitude of workloads at the same time.



Second, automation is faster. A human can execute multiple tasks in a certain amount of time, but

software can be way faster in doing the same operations.

Third, automation frees time for IT people to do more interesting and rewarding activities while daily

maintenance is managed by the automation solution.

In terms of vSphere tags, different solutions can be used: VMware vRealize Orchestrator, VMware

vRealize Automation, third party software such as Puppet, Chef, Ansible, all are able to interact with

vSphere and manage tags among the many capabilities they have.

An additional advantage of automation tools when dealing with tags is the possibility to integrate

tagging into other workflows. If an environment, for example, already has a process in place to deploy

a new virtual machine following a workflow, administrators can think about adding a new additional

step in the workflow itself where the user is requested to apply the desired tags to the virtual machine

he’s deploying. If the step is mandatory, administrators can be assured that the new virtual machine will

have proper tags from its initial creation, and no new virtual machine will remain untagged.

3.2.3 Tagging using Veeam ONE

An additional option for tagging is Veeam ONE™. Among the many different capabilities that this

software has, it can also manage and apply tags to vSphere objects.

Fig. 3: Rules in Veeam Business View to manage tags

By using the Business View inside Veeam ONE, administrators can classify and organize virtual machines

by rules that define a single parameter or a regular expression. Veeam ONE’s own tags can be synced

with vSphere tags, or it can directly use vSphere tags by importing and consuming them. Either way,

the final result is that any tagging in Veeam ONE is replicated into vSphere, so that the tags are always

in sync in both consoles.



4. Step 2: Create the rulesOnce the desired state has been defined, it’s time to “translate” the requirements in consumable objects

in the vSphere environment. That is, it’s time to create the needed tags.

Before starting the actual process of creation, a proper strategy around tag configuration and

consumption is needed. The two major options are a complete freedom in tag creation left to users,

or the creation of a defined “catalog” of tags that users can then consume. In terms of Availability, the

second option is preferred. This this way backup and replication jobs can be mapped to specific tags,

while a new random tag created by users may be not mapped to any job in the backend.

This brings the conversation to another big topic in a policy-based solution: The existence of two

different roles involved in the process. Policies, in the form of tags, are consumed in the front-end, but

what happens in the back-end?

There are going to be two different roles: Users (or tenants) and Providers (or administrators). Each have

different duties and tasks that can be summarized like this:

Fig. 4: Users and Providers in a policy-based architecture

Users, as explained in the previous chapter, interact with the front-end of the architecture. They define

the desired state of their workloads, and they apply tags to their own VMs. But policies, in the form of

tags and Veeam jobs mapped to those tags, are created in the back-end by Providers, who ultimately

are in charge of managing the infrastructure.

This separation between front-end and back-end, users and providers, is the very essence of a cloud-

like solution as the one described into this document. Users consume resources accessing a multi-

tenant environment leveraging self-service. Providers build, maintain and deliver the infrastructure

consumed by users.



4.1 Tags creationFollowing the separation of duties, tags are created by Providers.

To better organize them, tags are grouped in vSphere in categories:

Fig. 5: tags categories in vSphere

Thanks to categories, tags can be easily created and classified based on their function. For example,

Veeam will consume tags under the “RPO” and “Backup Encryption” category, while tags under the “VM

purpose” category are used by users to classify virtual machines based on their role in the environment.

You can see in the column named “Associable Entities” all the categories are related to virtual machines.

In theory, tags can be applied to any object, but since the atomic unit of processing data in Veeam is a

single VM, it’s better to limit the usage of Veeam-related tags to just VMs and not other objects:

Fig. 6: Limit tags to be associated to VMs only



With this configuration, a user is not allowed to tag dynamic containers like resource pools, and this is

good. Without this limit, an entire resource pool (or VM folder, or datastore) would be tagged with the

same tag, and so granularity of tagging would be lost.

Once categories are created, tags are defined and associated to the desired category:

Fig. 7: Overview of tags created in vSphere

For the purpose of this document, we created 4 different tags related to RPO values. The description

has been used to help users choose the right tag for their virtual machines. You can already imagine, by

looking at their names, that based on the desired RPO for a given VM, a specific tag will be applied.

4.2 The “No Backup” tagWhen in an environment, separation of duties between users and providers is applied. There’s a need

to guarantee proper interaction between the two. As the final goal of a data protection solution is to

protect all the workloads that require protection, providers (the backup administrators) need a way to

check that each virtual machine has received proper tags.

But since the tagging operation is completely delegated to users, what if a virtual machine has no tag

related to Veeam? Was it a miss, or an intentional decision?

For this reason, the concept of the “No Backup” tag is important.

Fig. 8: The “No Backup” tag

By creating and offering this special tag to users, providers offer them a way to tag those virtual

machines that are not requested to be protected. When a virtual machine is tagged with this tag,

providers can be assured the virtual machine was not simply forgotten, but it was a choice of the

application owner to not request protection for it.

Once the “no Backup” tag has been applied to all the desired virtual machines, only the non tagged VMs

are to be evaluated as missing by the providers. Different tools can be used to track VMs with missing

Veeam-related tags, from simple scripts to queries executed using vRealize Automation or other tools.



This information can also be obtained using Veeam ONE. This solution does not track virtual machines

with missing tags, rather it checks directly against both vSphere and Veeam Backup & Replication those

VMs that do not have any restore point.

This kind of report is important because if a virtual machine has not been tagged, there will be no

backup or replication job protecting it, but still the ultimate goal is to protect any workload, regardless

if it has been tagged or not. Tagging is a good solution, but it doesn’t need to become too rigid, and

backup administrators need to apply additional checks to guarantee proper data protection is in place.

Fig. 9: Alarm in Veeam ONE showing a virtual machine without any restore point.

By leveraging Veeam ONE alarms, administrators can be notified about any virtual machine that doesn’t

have any restore point stored into Veeam Backup & Replication, and with additional corrective actions,

can be automatically configured in the software. For example, administrators can create a new backup

job for these unprotected VMs as a temporary solution until proper tagging is applied.

Finally, a complete report of unprotected VMs can be created:

Fig. 10: Report of unprotected VMs

With this report, providers can interact with users and notify them about the missing VMs so users can

decide if they want to apply one of the available tags to their VMs, unless the reported VMs are those

with the “no backup” tag.



5. Step 3: Apply the rulesOnce the different rules have been created, tags have been created and made available to users, and

VMs have been tagged, it’s time to work in the back-end to apply those rules.

In the back-end, that is Veeam Backup & Replication, policies are consumed using jobs - either backup jobs

or replication jobs. As an environment grows in size and complexity, a multitude of jobs become difficult to

maintain, especially if they have to deal with single virtual machines per job, or small groups of VMs.

Also, in modern environments the list of virtual machines is changing daily as new VMs are constantly

deployed, modified, moved, and deleted. Instead of having a fixed list of virtual machines protected

in a given job, the ideal situation is to design a solution that can automatically adjust to the changes

happening in the environment. And the use of vSphere tags is perfect for this scenario.

5.1 Jobs based on tags in Veeam Backup & ReplicationWhen a new job is created in Veeam Backup & Replication, there’s a specific way to consume tags. Let’s

use the example of “RPO 4 hours:” This tag is designed to label virtual machines that require a backup

to happen every 4 hours.

When the job wizard arrives to the step of selecting the virtual machines to be protected, instead

of selecting single VMs or containers like datastore or resource pool, the “Add objects” pop-up also

has the possibility to browse vSphere tags.

Fig. 11: Select tags as a source of a Veeam backup job.



In this case, the backup administrator will select the “RPO 4 hours” tag as the object to be protected.

Next in the creation wizard, he will configure additional options, but the most important part is that the

schedule of the job will be configured to happen every 4 hours, like the tag suggests.

Fig. 12: Schedule the job to run automatically every 4 hours.

The final result will be an empty job at the beginning, not related to any specific VMs. At each execution

of the job, Veeam will poll in real-time from vCenter the list of virtual machines having the “RPO 4 Hours”

tag, and will process all those VMs.

From a policy point of view, the result will be that any VM with that tag will be processed according to

the policy. And the solution will adjust dynamically to any change. As soon as a VM is tagged, it will be

processed by this job, and in the same way as soon as a VM will not have this tag anyone, Veeam will

stop processing it, or it will process it according to a different policy.

By creating different jobs each mapped to a tag, backup administrators have created not just backup

jobs, but effectively “backup policies.”

The “no backup” tag will not be associated to any backup or replication job.



5.2 Dealing with backup filesVeeam Backup & Replication uses a proprietary file format to store backups. These files make backups

completely self-contained since there is no central database storing the information related to the

content of the backups themselves. Therefore, backups can be restored into a different location and

used even if the central console is lost.

Also, files are portable, since even the simple read of their name makes them transparently identifiable,

so administrators can move them at will with ease.

These files are populated by Veeam Backup & Replication with all the blocks extracted from the vSphere

environment during each execution of a backup job, regardless if the job is full or incremental. Thanks

to source-side deduplication and compression, duplicated blocks are removed from the backup file, so

that its final size is as low as possible, helping customers save space on their backup storage.

A single backup job creates one backup file for each execution, and the file itself contains blocks

belonging to all the virtual machines processed by the job itself. As said, this is helpful to improve

deduplication, but when administrators decide to use tag-based jobs, controlling the final size of the

backup file may become an issue since there’s no real control available to providers to limit the number

of times the same tag will be used by users. The final size of the backup file may become excessive,

leading to issues with the available space in a backup repository.

For this and other reasons, users should consider to upgrade their Veeam environments to Veeam

Backup & Replication v9 when it will be available, because there is a new feature coming that will help

in these situations: Per-VM backup chains.

With per-VM backup chains, a single job containing multiple VMs will not create any more than a single

file. Instead, each VM will be stored into a separated file. In a backup chain made with both full and

incremental files, each VM will have its own chain.

Without per-VM backup chains, the only other way to obtain the same small files would be to create

many small jobs, each containing either one VM, or just a few of them. But this makes the management

of the jobs impractical in general, and basically impossible with tags. Per-VM backup chains is a

capability of the Veeam backup repository, and it’s completely transparent to backup jobs. The backup

job can still hold multiple VMs, and the split will be made automatically at the repository. So large jobs

colleting several VMs with the same tag will benefit of the per-VM backup chains, without requiring any

reconfiguration or additional design.



6. RestoresSo far, we described how to automate backup operations. But a “cloud-like” solution could not be

considered complete if restores cannot be delegated in a multi-tenant fashion.

Veeam Backup & Replication offers complete support for restore delegation thanks to the Enterprise Manager.

Fig. 13: An overview of Veeam Enterprise Manager.

Enterprise Manager is a web portal where users can have a quick overview of the environment and

execute different activities with the additional advantage of a complete multi-tenant solution. While

the console of Veeam Backup & Replication is mainly designed for the administrators, and as such its

security is based on the windows rights of the machine where it is installed, Enterprise Manager is a

role-based solution, where different users can have different roles, applied to only parts of the vSphere

environment. As such, it’s a perfect solution to offer self-restore capabilities natively, without third party

components. Finally, Enterprise Manager can be accessed natively via its web interface, or via RestFUL

API, for those customers willing to integrate it into their custom developed portals.



6.1 Configure roles and scopesAdministrators can configure users’ access to Enterprise Manager to limit both the parts of the vSphere

environment the can work on, and both the activities they can do.

Fig. 14: Users and roles in Veeam Enterprise Manager

As in any role-based system, each user registered in Enterprise Manager needs to have a role. When a new

user is created, either a local user or one from Active Directory, it can have one of three available roles:

Fig. 15: Restore options for Restore Operators

Restore Operator is definitely the proper way to assign to users/tenants to enable self-service restore.

This allows users to see the restore points of their own virtual machines and items stored inside those

machines, and start restore operations from there.



Possible restore options are entire virtual machines, or even only single files or application items, as you

can see in fig. 15. In addition to this option, the important part is the configuration of the scope: The

part of the vSphere infrastructure the operator has access to.

Fig. 16: Possible scopes in Veeam Enterprise Manager

Administrators can decide if a Restore Operator is going to obtain access to backups of a dynamic

container of the vSphere environment, such as a resource pool or by tags. The first option is good for

mapping users belonging, for example, to a different Business Unit: As this unit is probably configured

as a resource pool in vSphere, having access only to the backups of VMs belonging to the resource

pool makes perfect sense. Or, by using tags as a scope operator can manage a specific type of virtual

machine. In our example, the database administrator may have the need to restore data in their

databases, regardless of the business unit they belong to.

Both options lead to a limited access of the Enterprise Manager, where the operator doesn’t see any

configuration option (this is in charge of the backup administrators) but has the minimum amount of

permissions required to complete a restore.

Fig. 17: Restore Operator view in Veeam Enterprise Manager

Restore Operators see only the tabs related to VMs and/or files, depending on how their user was configured.

With Enterprise Manager, administrators can delegate restores to users and offer a complete self-service

solution, without having users themselves access the Veeam Backup & Replication console.



6.2 Self restore portal for application ownersEnterprise Manager is a great solution, but it requires that every user is mapped against a role to obtain access

to it. This means there is an additional load on the backup administrators to configure each user, and the need

from time to time to change the configurations as people change role in the company, leaves or is hired.

If the restore needs are related to Microsoft Windows virtual machines, Enterprise Manager has an

additional option: Self restore portal for application owners.

The self restore portal is available for file-level restores of Windows virtual machines. When a user is

logged into a Windows VM joined to the Active Directory domain, its user is already authenticated

when the Self Restore portal is opened. Enterprise Manager reads this information automatically via the

browser API, checks if the user is a local administrator of the VM used to reach the portal, and in this

way automatic access is granted. Enterprise Manager then shows to the user only the backups where

he’s recognized as a local administrator.

Fig. 18: Veeam Self restore portal for application owners

With Self restore portal for application owners, administrators don’t have to manage delegations at all

since this is done automatically by Enterprise Manager during the access to the special URL

(https://enterprise_manager_IP:9443/selfRestore).

https://enterprise_manager_IP:9443/selfRestore



7. An integrated approachSo far, we discussed how to properly configure a policy-based Availability solution. But an environment

is not made with different silos, rather every different component needs to interact with all the others,

so that the overall environment is working at its best.

Backup administrators are in reality not only responsible for their own solution. This solution interacts

and can affect other components, and for this reason a proper design, deployment and management

needs to be done. Otherwise, by only focusing on this single solution, administrators can affect the

entire environment with their design choices.

Separation of duties between providers and users still means that providers are in charge of the good

standing of their environment. Simply defining the policies and letting them be consumed without

monitoring for example is dangerous.

Policies must be designed following the limits of the available resources.

Suppose you have a policy that allows users to run a full backup every hour. What happens if your

backup environment cannot guarantee this requirement? Excessive policies like this will ruin the

performances of the production environment or the backup environment, leading to damages,

downtime, data loss.

That’s why Veeam Backup & Replication is designed to consider every possible aspect of the

environment where it’s deployed, and not “just” offer data protection.

7.1 Performance growthA virtualized environment can start small, and then grow over time. When an administrator designs its

policies, those can be easily fulfilled at the beginning, but when the environment grows, and the number

of virtual machines to be processed is way bigger than what originally designed for, administrators need

to be sure their technology can still offer the same level of service designed at the beginning.

Offering an RPO of 4 hours with 50 virtual machines doesn’t require the same amount of resources as

an environment with 5,000 virtual machines.

Veeam Backup & Replication has different scalable components that can be added without modifying

the environment to keep performance at pace as the environment grows. If more data needs to be

processed, it’s as easy as deploying additional “proxies” and “repositories” to guarantee that backup

performance will still be the same even with 100 times the amount of virtual machines.



7.2 Protect the production environmentAn Availability solution is designed to protect a production environment, and for this reason, its first

directive should be not to harm the environment it’s supposed to protect.

A point solution designed to “do backups” is probably designed with just backups in mind. An

Availability solution, on the other hand, will take into account the available resources both in the

production and backup environment.

As the requirements for better Availability increase, better RPO are requested by users. In terms of

backup jobs for example, this means the need to execute them multiple times per day. An architect

should ideally design the production environment taking into account the resources needed to run the

workloads, AND to feed data to the Availability solution.

Think about storage I/O - if Veeam Backup & Replication needs to extract data from the production

storage multiple times per day, does this storage array have enough resources to run the virtual

machines and feed Veeam at the same time? Or are Veeam jobs going to reduce the performance of

the virtual machines because the underlying storage cannot satisfy both requests?

Availability also means maintaining performance “while” data protection activities are executed, and for

this reason, Veeam Backup & Replication has a feature called Backup I/O Control.

Fig. 19: Veeam Backup I/O Control

Backup I/O Control monitors in real-time the latency of vSphere datastores, and every time latency

goes above a configured threshold, backup jobs are throttled to guarantee latency never goes above

the desired value.

Talking in policy terms, it’s like having a desired state of the storage performance, and being

guaranteed by Veeam that the policy will never be violated.

Backup I/O Control is the perfect example of a feature that simple backup solutions will probably never

have, but a component that you can expect from a solution that offers complete Availability of the

environment it’s protecting.



Luca Dell’Oca (vExpert, VCAP-DCD, CISSP) is an EMEA Evangelist for Veeam

Software based in Italy. Luca is a popular blogger and active member of the

virtualization community. Luca’s career started in information security before

focusing on virtualization. His main areas of expertise are VMware and storage

design, with a deep focus on Cloud Service Providers and Large Enterprises.

Follow Luca on Twitter @dellock6

About Veeam Software Veeam® recognizes the new challenges companies across the globe face in enabling the Always-

On Business™, a business that must operate 24/7/365. To address this, Veeam has pioneered a

new market of Availability for the Modern Data Center™ by helping organizations meet recovery

time and point objectives (RTPO™) of less than 15 minutes for all applications and data, through

a fundamentally new kind of solution that delivers high-speed recovery, data loss avoidance,

verified protection, leveraged data and complete visibility Veeam Availability Suite™, which

includes Veeam Backup & Replication™, leverages virtualization, storage, and cloud technologies

that enable the modern data center to help organizations save time, mitigate risks, and

dramatically reduce capital and operational costs.

Founded in 2006, Veeam currently has 29,000 ProPartners and more than 135,000 customers

worldwide. Veeam’s global headquarters are located in Baar, Switzerland, and the company has

offices throughout the world. To learn more, visit http://www.veeam.com.

About the Author

https://twitter.com/dellock6

http://www.veeam.com/?ad=pr

http://www.veeam.com/data-center-availability-suite.html?ad=pr

http://www.veeam.com/vm-backup-recovery-replication-software.html

http://www.veeam.com



COMING SOON

Learn more and previewthe upcoming v9 release

vee.am/v9

NEW Veeam® AvailabilitySuite™ v9

RTPO™ <15 minutes forALL applications and data

Using Veeam and VMware vSphere tags for …docs.media.bitpipe.com › io_12x › io_128788 ›...

Documents

Transcript of Using Veeam and VMware vSphere tags for …docs.media.bitpipe.com › io_12x › io_128788 ›...