Upgrade to Veeam Backup & Replication v9 and leverage the...

Upgrade to Veeam Backup & Replication v9 and leverage the NEW features, step-by-step Luca Dell’Oca vExpert, VCAP-DCD, CISSP

Upgrade to Veeam Backup & Replication v9 and leverage the NEW features, step-by-step

2© 2016 Veeam Software

ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1 . Upgrade to Veeam Backup & Replication v9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 Acquire a proper license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1.2 Download the needed installation sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1.3 Upgrade to Veeam Backup & Replication v9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

1.4 Upgrade the installation to the latest update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

2 . Enable BitLooker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Enable BitLooker on existing jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Savings coming from BitLooker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 . Scale-Out Backup Repository and per-VM backup chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Create a new Scale-Out Backup Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Plan the migration using tags. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Take control of the migration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Migrations at bigger scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

About Veeam Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20



In this technical document, you will learn how to upgrade an existing environment to Veeam® Backup

& Replication™ v9, and leverage, step-by step, new features, including BitLooker™, per-VM backup

chains and Scale-Out Backup Repository™.

IntroductionVeeam Backup & Replication v9 introduced many new and exciting features. While some of them

can easily be enabled in an existing environment, others require additional planning because they

introduce important changes that result in different behaviors.

Technologies such as BitLooker, per-VM backup chains and Scale-Out Backup Repositories can

dramatically improve the backup performance of any environment, but before being introduced into

an existing environment, proper planning is necessary.

This white paper will describe a Veeam customer’s environment where Veeam Backup & Replication v8

was already installed. We will upgrade the software to v9, and then explain, step-by-step, the introduction

and configuration of BitLooker, per-VM backup chains and Scale-Out Backup Repositories.

1 . Upgrade to Veeam Backup & Replication v9In an existing environment where a customer is already using Veeam Backup & Replication v8, (Update 3,

Build 8.0.0.2084), the first step, in this case, is to upgrade the environment to the latest version of Veeam

Backup & Replication. At the time of this writing, the latest version was v9 (Update 2, Build 9.0.0.1715).

The Veeam version upgrade is totally safe because:

• No configuration or new option is ever enabled during any upgrade

• None of the features described in this paper are immediately enabled after an upgrade

• The upgraded v9 will keep behaving like v8 until we change one or more configurations.



1 .1 Acquire a proper license

Each Veeam Backup & Replication version requires a dedicated license. Since we are going to upgrade

a v8 installation, the installed license is related to v8:

Before upgrading to v9, we need to acquire an updated license created for a v9 installation. This can be

found on the licensing portal, as long as the customer has a valid maintenance contract. Once the license

file is retrieved, it can be verified by opening it with a text editor. Once open, it should read: Version=9.x

This means the license is correct for a v9 installation. This license will be used during the upgrade process.

1 .2 Download the needed installation sources

Once the license is retrieved, it’s time to download the needed installation media. At the time of this

writing, we needed two installation sources:

1. VeeamBackup&Replication_9.0.0.902.iso

2. VeeamBackup&Replication_9.0.0.1715_Update2.zip (https://www.veeam.com/kb2147)

The first file source is the main installer for v9. This will update a v8 installation to v9. Next, we can

immediately upgrade the v9 installation to v9, Update 2, using the second installer.

Both installation media can be obtained from the Veeam website.

https://www.veeam.com/manage_licenses.html

https://www.veeam.com/kb2147

https://www.veeam.com/vmware-esx-backup-download.html



1 .3 Upgrade to Veeam Backup & Replication v9

Next, we mount the ISO file directly in the Veeam Backup & Replication server, so that the installation

media starting screen shown below can be launched:

The installer will recognize that there is a previous installation in the machine, and for this reason,

it will immediately offer the upgrade button as the only enabled option. Every other option

will be inoperable at this time.

If Enterprise Manager has been previously deployed, we will be forced by the installer to upgrade

the Enterprise Manager first, or the Veeam Backup & Replication upgrade will not be possible.

If Enterprise Manager is installed on a different machine, remember to start the update there

first to upgrade this component.

In this scenario, only Veeam Backup & Replication is installed, which explains why the upgrade option

for Veeam Backup & Replication is the only available option.

To proceed, click the upgrade button.

NOTE: .NET Framework 4.5.2 is a prerequisite to install Veeam Backup & Replication v9. If this is not

first installed in the server, the upgrade process will offer to automatically install it.



Before proceeding to the upgrade, the installer, shown below, will list the existing

components to be upgraded:



After providing the new license to the wizard, the installer asks if the installation should use

the existing database as shown here:

The databased used in v8 is then upgraded to v9 during the installation as shown here:



The installation will proceed for a while, and at the end, the upgrade process will be finished, as shown here:

1 .4 Upgrade the installation to the latest update

Even before opening the console, it’s best to proceed to the installation of the latest available update.

Because different installed components will be immediately and forcefully updated when the console

is opened, it is preferable to perform this operation only once, instead of for both the main v9 installation

and its update. The upgrade process may take a while because some components might be installed

in remote locations. If needed, updates can be deferred by unselecting the managed servers you don’t

want to upgrade. A common use case is when a managed server is shared between different Veeam

Backup & Replication servers that each use different versions.

Here, after we have unpacked the zip file and obtained the installer file (VeeamBackup&Replic

tion_9.0.0.1715_Update2.exe is the file used to install Veeam Backup & Replication v9, Update

2), the .exe file is executed. Once launched, the upgrade process is completely automated,

with no options to be selected. After a while, the upgrade process will be completed.



Upon starting the Veeam Backup & Replication software from the desktop icon, the first difference,

compared to v8, will be immediately visible, as shown here:

Veeam Backup & Replication v9 introduced, among many enhancements, a new Standalone Console.

This component is installed by default in the Veeam Backup Server, but it can also be installed in any

remote machine and used to connect to and manage the Veeam Backup Server. Multiple users can

connect to the same Veeam Backup Server at the same time by using the Standalone Console.



As soon as login is completed, the Veeam Backup Server will warn the user that some components

need to be upgraded so the upgrade process can be completed:

Different components are automatically updated in each Veeam server. Once the user logs into

the console, he can check the build version of the software as shown here:

Note that this splash screen can be reached by opening, from the main manu, Help — About. Although

the upgrade will now be complete, every job will still be configured as it was configured in v8. To verify

that the upgraded software is functioning as expected, it’s suggested that you allow the existing jobs

to run for a few days before proceeding to enable the new features.



2 . Enable BitLookerOne of the three technologies listed in the introduction is BitLooker.

BitLooker is actually the original code name for the feature listed in the software interface as Exclude

deleted files blocks. The name has now survived the development period and can be found in many

documents related to Veeam Backup & Replication v9, including the User Guide. BitLooker continues

to be used when referring to this feature.

With BitLooker, Veeam Backup & Replication does not copy “dirty” data blocks — blocks marked

as deleted on the VM guest OS — to the target location. This allows you to reduce the VM backup

or replica size and increase the job performance.

This option works on Windows-based VMs with NTFS file systems. Veeam Backup & Replication accesses

the MFT file on the VM guest OS to identify deleted file blocks, and zeros-out these blocks. If a data

block of the VM image contains only the deleted file blocks, Veeam Backup & Replication does not read

this data block from the source volume. If a data block of the VM image contains zeroed-out blocks and

other data, Veeam Backup & Replication copies this block to the target. Due to data compression, data

blocks marked as deleted are compressed, and the size of the resulting backup or replica file is reduced.

2 .1 Enable BitLooker on existing jobs

Regardless of if you have backup jobs (or other type of jobs) with only Windows-based VMs in it, or a mix

of different operating systems, it’s a good (and safe) choice to enable BitLooker in any job. Non-windows VMs

(technically, any machine not using an NTFS filesystem) will simply not benefit from this feature and will be

processed as before. This is the reason why the option is enabled by default on new jobs created in v9:



In large environments with several jobs, we can enable BitLooker on any job

automatically by using PowerShell:

asnp VeeamPSSNapin

foreach ($Job in Get-VBRJob | where {$_.JobType -eq “Backup” -or

$_.JobType -eq “Replica”})

{

$Options = $Job.GetOptions()

$Options.ViSourceOptions.DirtyBlocksNullingEnabled = $True

$Job.SetOptions($Options)

}

2 .2 Savings coming from BitLooker

In the small environments we are using here, there are 15 VMs protected by a single job. This makes

it fairly easy to enable BitLooker.

After enabling BitLooker and letting it run for a few weeks, we saw some decent differences in storage

consumption. Depending on the amount of files regularly deleted inside the guests, results could vary

from ours in other environments.

BitLooker can save a good percentage of backup storage space. The savings obviously depend

on the size of the environment and percentage of Windows machines. In any case, the saved space

will help in the next migration phase, where we will need to store two copies of each VM for a while.

3 . Scale-Out Backup Repository and per-VM backup chainsScale-Out Backup Repository and per-VM backup chains are the next two features

to be introduced in the existing environment.

Even though these two features can exist independently, when used together, they make a lot more

sense. In Scale-Out Backup Repositories, per-VM backup chains is the global setting for the entire

group, and there is no way to manage the option at the single extent level once the extent itself

is added to a Scale-Out Backup Repository.

If you want to learn more about Veeam Scale-Out Backup Repository, read this dedicated white paper

published on March 2016: A Deep Look at Scale-out Backup Repository. This white paper includes all

design and deployment information for Veeam Scale-Out Backup Repositories, as well as policies about

file placements and best practices.

The Scale-Out Backup Repository algorithm can place backup files in any available free space. With

per-VM chains, the biggest backup file is no longer the entire backup set (as seen in the previous

chapter), but instead, is a backup file containing a single VM. This means the files will be smaller and

the placement algorithm will more easily be able to select free-space chunks.

https://www.veeam.com/wp-scale-out-backup-repository.html



In addition, per-VM backup chains are written concurrently in the backup repository by running

multiple backup streams. This occurs even for only one backup job. As a result, a single backup

job run by the customer, which was only able to generate one I/O stream earlier, will now be much

faster due to the multi-threaded I/O activities.

These steps require some planning, even in a small environment, because the split of backups from

single files to per-VM chains requires the creation of a new full backup for that VM. This means that

the same VM has to either be stored twice (with the VM listed in both old and new backup jobs),

or there is a risk of becoming unprotected (when the VM is removed from the old backup job,

but not added to the new one).

When moving an environment to per-VM chains, the option is enabled at the repository level as shown here:

Any backup job or backup copy job using this repository as a target will start to use per-VM backup

chains. This doesn’t happen immediately, though. Here, we have to run an active full backup

so the per-VM chains will be stored in the repository. This customer, however, is using Forever Forward

Incremental, which has no active full, except for Day 1. As long as we do not run an active full, the job

will still be stored in a single backup file, even if the per-VM chains are enabled. This process will allow

us to plan the switch even better, as well as with a greater level of control.



3 .1 Create a new Scale-Out Backup Repository

First, we need to create a new Scale-Out Backup Repository taking advantage of placement policies

and the expandability of this new technology in Veeam Backup & Replication v9. Right now, the two

storage systems available in the environment are used independently. We don’t want to automatically

import the existing backup folders into the new scale-out system. These are the existing repositories:

We are using already Vessraid_1720i_R5 for the actual backup job. For this reason, we start by

creating and an additional folder in the T: volume, called SOBR (the acronym for Scale-Out Backup

Repository). We also need to create the same folder in the other array, Vessraid_1720i_R10. We then

end up having this new configuration:

Next, we will create the new Scale-Out Backup Repository using the two newly created extents

as members, and the data locality as the placement policy. The new repository here ends up having

5.9 TB of overall capacity and 4.3 TB of free space. NOTE: This is the sum of the two storage arrays.



3 .2 Plan the migration using tags

Now that the target for the new backup job is ready, and because this customer is using VMware

vSphere as his virtualized platform, we can create a new tag in vCenter, called per-vm, shown here

This tag’s plan and its usage starts with creating a new backup job, and because the job is newly

created using Veeam Backup & Replication v9, the first execution will be an active full.



We will use vSphere tags in both the new and old backup jobs. In the first backup job, we will use

the SOBR as the target (with per-VM backup chains enabled by default, as in any Scale-Out Backup

Repository), and the vSphere tag as the dynamic object to select which VMs are to be protected:

As you can see below, the size of the VMs protected using this tag is now 0.0 KB:

This size is on purpose because we have not tagged any VMs in the vSphere environment. This

is a critical step in the migration process: By using the same tags in both jobs, VMs will be included

in the new job and excluded from the existing job at the same time. Because of this and before starting

the tagging operation, we also need to add this tag to the existing backup job as an exclusion this time.



3 .3 Take control of the migration process

Thanks to the use of tags, we can now have day-by-day control over which VMs are moved from the old

to the new backup job as soon as a VM is tagged.

The new backup job will process this VM and, at the same time, the VM will go into the exclusion list

of the existing job. The net result is that the machine will now be protected by the new job, while

the old job will hold the previous restore points.

By using tags and tagging one or more VM each day, we can decide how many VMs are to be

processed by the new job, so that two impacting factors can be limited:

1. As the new job creates an active full, and another active full is stored in the old backup job, each VM

consumes double the space in the backup repository. By moving a few VMs at a time into the new

backup job, we can control the storage consumption.

2. An active full requires more resources from the production storage to be executed, both in terms

of I/O and execution time. By simply switching the old job to the new format, we would likely

create huge issues for the production storage because, every VM on the first day would be

processed to create the new active full.

Because we planned to tag two of the 15 VMs each day, the migration should be completed in two

weeks. In larger environments, administrators can plan the migration differently, depending on their

needs and the available resources. For tagging, PowerShell scripts can be used so that multiple VMs

can be automatically tagged each day, and so we can verify which VMs have already been tagged

and which are still to be tagged. This way, we won’t forget what has and has not been tagged.



This PowerShell command returns the list of virtual machines with the tag “per-vm” already applied:

Get-VM -Tag “per-vm”

During the migration phase, it may be more helpful to check which VMs are not yet moved to the new

job. These VMs are without the “per-vm” tag. Since this is the only tag we created in the environment,

we can search for VMs with no tags:

get-vm | ?{ (get-tagassignment $_) -eq $null}

The result is a list like this:

When the migration is completed, there are no more VMs with the missing tag, because they

all are now managed by the new job.

At this point, we must wait two weeks (the retention period configured by the customer in the existing

job) before being able to delete the previous job and its backup files. This is because we don’t yet have

two weeks’ worth of retention in the new job, so we are keeping the previous as a guarantee.

After migration to the new job has been completed and we’re successfully using both Scale Out Backup

Repository and per-VM backup chains, we can then decide to keep the dynamic list of VMs created using

vSphere tags. Or, we can decide to revert the selection back to the original version, the entire vCenter

list of VMs in this case (it could be a datacenter, a resource pool, a datastore or another dynamic object).



Whatever the choice, no additional processing of VMs is required. Every VM will be identified by its moRef

(Managed Object Reference) ID and only be processed once. The moRef ID is a unique identifier used

in any vSphere environment, and every object has its own moRef ID. Veeam uses moRef IDs to identify

VMs, so that, even if there’s a change like VM name, location, or the container object as in this case,

the VM will still be clearly identified and will not be processed from scratch with a full backup.

3 .4 Migrations at bigger scale

In this white paper, we used a small environment to explain a possible procedure to migrate an existing

environment to Veeam Backup & Replication v9 and leverage v9’s new capabilities.

In larger environments, customers and their architects should take additional care when planning

a migration because a larger number of VMs require different design choices.

First of all, the search for VMs that have not yet been migrated could lead to different results if you use

the criteria of not having any tag. It can happen in large environments that multiple tags and categories

are applied to every VM. The safest way to list VMs that are not yet migrated to per-vm chains is to list

VMs that do not have the per-vm specific tag:

Get-VM -Name * | ?{$_.Tag -ne “per-vm”}

Finally, a consideration about job size and number of VMs. Even if performance using per-vm chains

is greatly improved, having all VMs into a single job is not an ideal solution. In our experience

on the field, we have seen decent performance for jobs with 250 - 300 VMs. However, when doing

sizing for backup servers, we suggest that you assume 30 VMs for jobs without per-vm chains

enabled, or 90 VMs for jobs with per-vm chains.

ConclusionVeeam Backup & Replication has a successful history of easy and transparent upgrade processes

because no modification is ever made to existing deployments. Every new feature is disabled upon

upgrade, so that customers can choose if and when to enable and start to leverage a given feature.

In this white paper, we have shown how to successfully implement two major features, Scale-Out

Backup Repository and per-VM backup chains, in an existing environment by adopting a step-by-step

procedure to minimize the impact on the existing Veeam environment.

By properly designing migration plans and analyzing the impact of different changes, Veeam customers

can safely and successfully implement any new feature available in Veeam Backup & Replication v9.



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 Always-On Enterprise™ 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 41,000 ProPartners and more than 205,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 AuthorLuca Dell’Oca is EMEA Cloud Architect for Veeam Software. Based in Italy, Luca

is also popular blogger and an active member of the virtualization community.

At Veeam, Luca works with the biggest service providers and telecommunication

companies to help them use at full potential Veeam technologies developed

for Cloud and Service Providers. Luca is the author of the Veeam Cloud Connect

book, and several papers related to service provider and cloud technologies.

Luca holds VCAP5-DCD and CISSP certifications, and he has become the first

worldwide VMCE (Veeam Certified Engineer).

Follow Luca on Twitter @dellock6

https://www.veeam.com

https://www.veeam.com/data-center-availability-suite.html

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

https://www.veeam.com/

https://twitter.com/dellock6



NEW Veeam Availability Orchestrator

Disaster recovery orchestration for the Enterprise

Upgrade to Veeam Backup & Replication v9 and leverage the...

Documents

Transcript of Upgrade to Veeam Backup & Replication v9 and leverage the...