Veeam Backup and Replication Best Practices Deploy and Configure VMWare

Veeam Backup & Replication
for VMware
Version 6.x
Best Practices
for Deployment & Configuration
March, 2013
Tom Sightler
Solutions Architect, Core Products
Veeam Software
2013 Veeam Software.

All rights reserved. All trademarks are the property of their respective owners.
No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval
system, or translated into any language in any form by any means, without written permission
from Veeam Software Inc (Veeam). The information contained in this document represents the
current view of Veeam on the issue discussed as of the date of publication and is subject to change
without notice. Veeam shall not be liable for technical or editorial errors or omissions contained
herein. Veeam makes no warranties, express or implied, in this document. Veeam may have
patents, patent applications, trademark, copyright, or other intellectual property rights covering
the subject matter of this document. All other trademarks mentioned herein are the property of
their respective owners. Except as expressly provided in any written license agreement from
Veeam, the furnishing of this document does not give you any license to these patents,
trademarks, copyrights, or other intellectual property.
Important
Please read the End User Software License Agreement before using the accompanying software
program(s). Using any part of the software indicates that you accept the terms of the End User
Software License Agreement.
2 | Veeam Backup & Replication | BEST PRACTICES FOR DEPLOYMENT & CONFIGURATION |
REV 1
CONTENTS
CONTENTS.................................................................................................................... 3
CONTACTING VEEAM SOFTWARE............................................................................... 5
ABOUT THIS DOCUMENT ............................................................................................ 6
COMPONENTS OVERVIEW .......................................................................................... 7
VEEAM BACKUP SERVER ........................................................................................................................... 7
PROXY SERVER .......................................................................................................................................... 8
REPOSITORY .............................................................................................................................................. 8
Windows Server ................................................................................................................. 8
Linux Server ......................................................................................................................... 9
CIFS (SMB) Share ................................................................................................................ 9
OPTIONAL COMPONENTS ........................................................................................................................ 9
Veeam Backup Enterprise Manager ........................................................................... 9
Veeam Backup Search ..................................................................................................... 9
U-AIR Wizards................................................................................................................... 10
Veeam Explorer for Exchange ................................................................................... 10
INFRASTRUCTURE AND PROCESSES......................................................................... 12
BACKUP .................................................................................................................................................. 12
Onsite Backup .................................................................................................................. 13
Offsite Backup .................................................................................................................. 13
REPLICATION .......................................................................................................................................... 14
Onsite Replication .......................................................................................................... 16
Offsite Replication .......................................................................................................... 16
RECOVERY & VERIFICATION .................................................................................................................. 18
SureBackup ....................................................................................................................... 18
Recovery ............................................................................................................................ 19
UNDERSTANDING VEEAM BACKUP & REPLICATION OPTIONS ............................... 21
HOW IT WORKS: BACKUP METHODS ................................................................................................... 21
Reversed Incremental ................................................................................................... 22
Forward Incremental..................................................................................................... 22
HOW IT WORKS: TRANSPORT MODES ................................................................................................. 24
Direct SAN ......................................................................................................................... 24
Virtual Appliance ............................................................................................................ 24
Network Mode ................................................................................................................. 25
HOW IT WORKS: RETENTION POLICIES ................................................................................................ 26
DE-DUPLICATION ................................................................................................................................... 26
COMPRESSION........................................................................................................................................ 27
INDEXING AND SEARCH ......................................................................................................................... 27
DEPLOYMENT SCENARIOS ........................................................................................ 29
SMALL-SIZE ENVIRONMENT OR PILOT: SIMPLE DEPLOYMENT ........................................................... 29
MEDIUM-SIZE OR LARGE-SCALE ENVIRONMENT: ADVANCED DEPLOYMENT ................................... 30
LARGE, DISTRIBUTED ENVIRONMENT: DISTRIBUTED DEPLOYMENT................................................... 33
INTERACTION WITH VSPHERE VIRTUAL ENVIRONMENT ........................................ 35
REV 1
VCENTER SERVER ................................................................................................................................... 35
Health.................................................................................................................................. 35
Capacity ............................................................................................................................. 35
Connectivity ..................................................................................................................... 35
Maintenance .................................................................................................................... 36
IMPACT OF SNAPSHOT OPERATIONS.................................................................................................... 36
Snapshot Creation ......................................................................................................... 36
Snapshot Open ............................................................................................................... 36
Snapshot Removal ......................................................................................................... 37
How to Mitigate? ............................................................................................................ 37
SECURITY ................................................................................................................................................ 39
NETWORK CONNECTIVITY ..................................................................................................................... 39
Veeam Backup Server Connections ........................................................................ 39
Backup Proxy Connections ......................................................................................... 40
Veeam Backup Enterprise Manager Connections ............................................. 42
RESOURCE PLANNING AND OPTIMIZATION ............................................................ 43
PLANNING FOR THE SOURCE................................................................................................................. 43
PLANNING FOR PROXIES ....................................................................................................................... 45
Physical or Virtual? ......................................................................................................... 45
Sizing ................................................................................................................................... 46
Choosing Transport Mode .......................................................................................... 47
PLANNING FOR REPOSITORIES .............................................................................................................. 47
Understanding the Impact of IOPS on Backup Performance ........................ 47
The Cost of Forward Incremental............................................................................. 48
Estimating Repository Capacity ................................................................................ 48
Deduplicating Storage Compatibility .................................................................... 49
Examples............................................................................................................................ 49
SIZING VEEAM BACKUP & REPLICATION SERVER................................................................................. 50
PLANNING FOR DATA RECOVERY & VERIFICATION ............................................................................. 51
Connection to NFS Server ........................................................................................... 51
Reaching Optimal Performance ............................................................................... 51
JOB SETUP .................................................................................................................. 53
OBJECT SELECTION ................................................................................................................................ 53
SETTING DE-DUPLICATION AND COMPRESSION LEVEL....................................................................... 54
CHOOSING BACKUP METHOD .............................................................................................................. 55
LOAD BALANCING ................................................................................................................................. 55
PLANNING FOR DR: CONFIGURATION BACKUP ....................................................... 57
REV 1
CONTACTING VEEAM SOFTWARE

At Veeam Software, we value feedback from our customers. We care about assisting you quickly
with technical support. Our mission is to listen to you and build the tools that you need.
Customer Support
Should you have a technical concern, suggestion or question, please visit our Customer Center
Portal at cp.veeam.com to open a case, search our knowledge base, reference documentation,
manage your license or obtain the latest product release.
Online Support
If you have any questions about Veeam Backup & Replication, you can use the following
resources:
Full documentation set at Veeam documentation page
Community forum at forums.veeam.com
Company Contacts
For the most up-to-date information about company contacts and office locations, please visit
www.veeam.com/contacts.html.
REV 1
ABOUT THIS DOCUMENT

This document addresses the key factors that must be considered to properly deploy the Veeam
Backup & Replication solution (version 6.0 and later). It explains deployment and configuration
options, as well as backup methods available, and describes the impact of these choices.
The document is intended primarily for solution designers and architects. To receive the full
benefit of the information presented, at least intermediate level of knowledge of VMware virtual
infrastructure and a basic understanding of Veeam Backup & Replication are required.
The following issues will be addressed in this document:
Architecture and main components overview
vSphere virtual environment considerations
Job setup and scheduling
Scalability and sizing
Deployment strategies
Hardware integration
Application-specific considerations
Reference architectures
To read more about Veeam Backup & Replication, you can refer to Veeam Technical
Documentation page.
Document Revision History

Revision #
Date
Description of Changes
Revision 1
28/01/2013
Initial version of the document for Veeam Backup & Replication v6.x
Revision 2
11/03/2012
Minor text edits and graphics update.
REV 1
COMPONENTS OVERVIEW
Before planning your Veeam Backup & Replication deployment, you should understand how the
solution works, know the factors that can influence performance, availability, storage space,
security and scalability of the solution. You should thoroughly understand solution architecture,
know what your options are, and then decide which best meets you needs.
Veeam Backup & Replication leverages the capabilities of a virtualization hypervisor to provide
comprehensive backup and replication of the virtual machines that are running within the
virtualized environment. With VMware vSphere, the hypervisor is used to take consistent
snapshots of the virtual disks attached to the VM, and Veeam Backup & Replication uses this
snapshot to create either a replica of the VM, or a compressed, deduplicated backup copy of the
VM.
The core components of the solution are:
Veeam Backup Server the brain of the solution, responsible for job management and
scheduling, indexing tasks, and general orchestration of the backup and replication
environment.
Proxy servers the muscle for the solution. These servers read data from the VM
snapshots, deduplicate and compress that data, and send it on its way. In the case of
replication, they also receive the replica data and write it to the new replica, acting as the
data movers to transfer data from the source to the target environment.
Repositories these systems provide the memory, storing backup images for future
restores, and important meta-data used during backup and replication. A repository may
be a Windows or Linux server or a NAS device which supports CIFS access.
The sections below describe these components in more detail; you can also refer to Veeam Backup
& Replication - Architecture and Components online training video.
Veeam Backup Server

The Veeam Backup Server is the center of the Veeam Backup & Replication architecture. It is here
that all backup jobs are defined, managed, and monitored. The scheduler then executes these
jobs, communicating with vCenter, taking snapshots, allocating proxies and repositories and
monitoring job progress.
The typical workflow of a backup job is as follows:
1.
Scheduler starts Job Manager processes based on each jobs configured schedule.
2.
Job Manager connects to vCenter to enumerate objects in the job and places them in
the job in the order specified during the Job creation wizard.
3.
Job Manager verifies repository availability (online, concurrent process limit not
reached).
4.
Job Manager selects for object for processing and elects most efficient proxy
available taking into account factors such as processing mode, proximity to data, and
current load.
5.
Job Manager assigns the VM backup to a proxy and performs the required setup such
as application-aware processing, snapshot creation, hot-add processing, and others.
6.
Job Manager assigns any session-specific settings, such as bandwidth throttling, and
instructs proxies to begin the data transfer.
After object processing is completed, the Job Manager cleans up, gathers stats, and moves to next
object, starting over at step 4.
REV 1
After last object is processed, the Job Manager gathers all backup information and global job
statistics, and exits.
Proxy Server
The primary role of the proxy server is to provide an optimal route for backup traffic and enable
efficient data transfer. Therefore, when deploying a backup proxy, you must understand the
connectivity between the backup proxy and the storage with which it is working.
Depending on the type of connection, the backup proxy can be configured in one of the following
ways (starting from the most efficient):
A physical machine used as a backup proxy should have direct SAN access to the storage
on which VMs reside, via a direct Fiber Channel or iSCSI connection. This way, the backup
proxy can retrieve data directly from the storage in the most efficient manner.
A virtual machine used as a backup proxy will use the VMware Hot-Add feature to access
VM disks on the storage. This type of proxy also enables LAN-free data retrieval.
Guidelines for sizing and configuring your proxy servers will be provided in the Planning for
Proxies section later in this document.
Repository
A backup repository is a server location used by Veeam Backup & Replication jobs to store backup
files, copies of VMs and metadata for replicated VMs. Technically, a backup repository is a folder on
the backup storage. Note that each job can use only one repository as its destination storage, but
one repository can be used by multiple jobs in parallel. You can balance the load across your
backup infrastructure by setting up several repositories in your environment and limiting the
number of parallel jobs for each one.
In the Veeam backup infrastructure, you can use one of the repository types described below.
Windows Server
In this configuration, the storage can be a local disk, directly attached disk-based storage (such as a
USB hard drive), or iSCSI/FC SAN LUN, or any device that appears as a drive letter at the system
level.
Note
Network drives mapped in user profiles will not work as they are only available during the
interactive login session. If necessary to use them as repository locations, please select the
CIFS/SMB repository and provide the full UNC path and authentication information.
On a Windows repository, Veeam Backup & Replication deploys a local Veeam agent (when you
add a Windows-based server to the product console, Veeam Backup & Replication installs a set of
components, including the Veeam Backup Proxy Service with Veeam agent, on that server).
When any job addresses the repository, the agent on the repository establishes a connection with
the source-side agent on the backup proxy, enabling efficient data transfer over LAN or WAN.
Windows repositories can be configured to function as vPower NFS Servers. In this case, Veeam
Backup & Replication will run the vPower NFS Service directly on the backup repository (namely,
on the managing Windows server to which storage is attached) and provide ESX(i) hosts with
transparent access to backed up VM images stored on the repository. For more details, refer to the
Planning for Data Recovery & Verification section.
REV 1
Linux Server
The storage can be a local disk, directly attached disk based storage (such as a USB hard drive), NFS
share, or iSCSI/FC SAN LUN in case the server is connected into the SAN fabric.
On the Linux repository, Veeam Backup & Replication deploys and starts the Veeam agent when a
job addressing this repository is launched. The agent establishes a connection with the source-side
agent on the backup proxy, enabling efficient data transfer over LAN or WAN.
CIFS (SMB) Share

CIFS (SMB) shares do not support Veeam agents, therefore data sent to the SMB share is written
directly from a proxy server assigned to the job (by default, the role of such a proxy server is
performed by the Veeam Backup server). However, if you plan to move VM data to an offsite CIFS
repository over a WAN link, it is recommended that you deploy an additional proxying Windows
server in the remote site, closer to the CIFS repository. Veeam Backup & Replication will deploy a
Veeam agent on that server, which will improve data transfer performance: the efficient Veeam
traffic stream will be sent between two proxies while keeping the CIFS traffic local to the storage
device.
Optional Components
Veeam Backup Enterprise Manager
Veeam Backup Enterprise Manager is an optional component intended to simplify the daily
management and administration of the Veeam Backup and Replication environment. This
component is typically deployed when you have multiple backup consoles/sites to manage.
For example, an organization may have two Veeam Backup servers: one in production
environment, used for backup jobs, and another at the DR site, for the replication jobs. For such
scenario it is worth installing Veeam Backup Enterprise Manager to have visibility across two
backup servers (sample scenario will be described later in this guide).
Veeam Backup Enterprise Manager federates Veeam Backup servers and offers a consolidated view
of these servers through a web browser interface, so that you can centrally control and manage all
jobs through a single pane of glass, edit and clone jobs, monitor job state and get reporting data
across all backup servers. Veeam Backup Enterprise Manager also enables you to search for
indexed Windows guest OS files in the current and archived backups across your backup
infrastructure, and restore these files in one click. For more information on guest OS indexing,
please refer to the section below.
Note
Using Veeam Backup Enterprise Manager to perform file search is recommended for virtual
infrastructures with a number of indexed VMs under 100; alternatively, use Veeam Backup Search.
You can install the Veeam Backup Enterprise Manager components on the same machine, either
physical or virtual, co-install components with Veeam Backup & Replication, or set up all
components separately on the machines meeting appropriate system requirements. For detailed
information on installing and configuring Enterprise Manager, please refer to Enterprise Manager
User Guide.
Veeam Backup Search

Veeam Backup & Replication enables you to perform quick and accurate searches for guest OS files
in a backed up VM without the need to restore it. This can be useful, for example, if a file you need
REV 1
has been deleted on the VM and you want to restore it from a backup. Once you find a necessary
file, you can use Veeams file-level restore to recover the file from the VM backup.
Note
At present, the search functionality is supported for Windows-based VMs only.

To be able to perform a search within the VM image backup, you need to enable file indexing in
properties of a corresponding backup job. When such a backup job is run, Veeam Backup &
Replication creates a catalog, or index, of the VM guest OS files and stores index files on the Veeam
Backup server in the C:/VBR Catalog/Index/Machines/[vm_name] folder. Creation of index is
extremely fast and has minimal impact on network and VMware environment.
Once the index is created and stored on backup servers, the indexing service on Veeam Backup
Enterprise Manager performs index replication it aggregates index data for all VM image
backups from multiple backup servers. This consolidated index is stored on the Veeam Backup
Enterprise Manager server in the C:/VBR Catalog/Index/catalog and is used for search queries.
With a relatively small number of backups, search for guest OS files in backups is performed with
Veeam Backup Enterprise Manager. However, if you frequently need to search through a great
number of backups (more than 100 VMs or more than 10 million files), it is recommended to
configure the Veeam Backup Search - an optional component in the backup infrastructure that is
used for the purpose of search performance optimization.
Veeam Backup Search is installed on a dedicated Microsoft Search Server to streamline VM guest
OS files search in large-scale virtual deployments. It uses Microsoft Search Server functionality to
crawl content in the shared VBRCatalog folder on the Veeam Backup Enterprise Manager server
and to create a content index on the Search Server that is used to process search queries.
For detailed information on Veeam Backup Search, please refer to the User Guide.
U-AIR Wizards
Universal Application-Item Recovery (U-AIR), enabled by the Veeam vPower technology, allows
you to recover individual items from any virtualized application.
For such applications as Active Directory, Microsoft SQL and Microsoft Exchange, U-AIR is a wizarddriven process that is, you can recover necessary items from applications using applicationspecific wizards.
For other applications, U-AIR is user-driven that is, Veeam Backup & Replication starts the
application and all components required for its proper work in a virtual lab so that users can
connect to that application and recover items themselves.
U-AIR wizards are not tied to the Veeam Backup & Replication installation these are standalone
components that can be downloaded, installed and updated independent of the product release.
You can install U-AIR wizards on any machine in your production environment from which you
plan to perform the restore process.
For details, see the Veeam Backup & Replication Help and U-AIR Wizards User Guide.
Veeam Explorer for Exchange

Veeam Explorer for Exchange is a free tool available to users of Veeam Backup & Replication
starting with version 6.1 (in all editions, including Free Edition). It allows you to browse Microsoft
Exchange 2010 database files and restore necessary items, such as mailboxes, folders, messages,
tasks, contacts and so on. Instead of fully restoring and starting the VM with the Microsoft
Exchange Server, you can use Veeam Backup & Replication capabilities to extract the necessary
Microsoft Exchange database from the backup file and then use Veeam Explorer for Exchange to
browse and restore individual items. Restore options include:
Exporting mailbox folders and items as Personal Folder Files (.pst)

Saving mailbox items as Microsoft Exchange Mail Documents (.msg)
Sending mailbox items as attachments via email
REV 1
Restoring mailbox folders and items into their original location (available only with Veeam
Backup & Replication Enterprise Edition)
Veeam Explorer for Exchange can be downloaded and installed independently from other Veeam
Backup and Replication components.
Important
Consider that Veeam Explorer for Exchange requires full access to Microsoft Exchange database
files for item recovery. This level of access is usually granted to a very limited number of employees
within the organization. If you would like to allow less privileged users to perform recovery of
Microsoft Exchange items from backups, you can use the Application-Item Recovery (AIR) wizard
for Microsoft Exchange.
REV 1
INFRASTRUCTURE AND PROCESSES

This section briefly reminds you of backup and replication infrastructure and processes. For the
detailed description, as well as for information on other processes (recovery verification, data
recovery, quick migration and so on), please refer to the User Guide and other product resources.
You can also view the Veeam Backup & Replication - How It Works online training video.
Backup
The backup infrastructure comprises the following components:
One or more source hosts with associated datastores
One or more backup proxy servers
Backup repository
The source host and the repository produce two terminal points between which VM data is moved.
Backup data is collected, transformed and transferred with the help of Veeam agents.
Veeam Backup & Replication uses a two-agent architecture one agent interacts with the source
host, and the other one interacts with the repository. The agents communicate with each other
and maintain a stable connection. All backup infrastructure components engaged for the job make
up a data pipe. VM data is moved over this data pipe block by block processing of a single VM
includes multiple processing cycles.
When a new backup session is started, the target-side agent obtains job instructions and
communicates with the source-side agent to begin data collection.
1.
The source-side agent accesses a VM image and copies VM data using one of VMware
transport modes, as prescribed by the proxy server settings. While copying, the sourceside agent performs additional processing it consolidates the content of virtual disks by
filtering out overlapping snapshot blocks, zero-data blocks and blocks of swap files.
During incremental job runs, the agent retrieves only those data blocks that have
changed since the previous job run. Copied blocks of data are compressed and moved
from the source-side agent to the target-side agent.
2.
The target-side agent deduplicates similar blocks of data and writes the result to the
backup file in the backup repository.
After a backup job completes, the resulting backup file is written to the backup repository that you
have selected as a backup target. Veeam Backup & Replication creates a full backup file (VBK)
during the first run of a backup job. During every subsequent job run, it copies changes that were
made to the VM since the last backup, whether full or incremental. Depending on the backup
method you select, Veeam Backup & Replication handles incremental changes differently:
Note
If you use the incremental backup mode, Veeam Backup & Replication saves
incremental changes to an incremental file (VIB) in addition to a full backup file (VBK)
on the backup repository.
If you use the reversed incremental backup mode, Veeam Backup & Replication
injects copied changes to the full backup file, and saves replaced blocks of data as a
reversed increment file (VRB) in addition to the full backup file (VBK) on the backup
repository.
To review backup methods in detail, you can refer to the How It Works: Backup Methods section of
this document, Veeam Backup & Replication Online Help, or How It Works online training video.
Also, in addition to backup files, Veeam Backup & Replication creates a backup metadata file (VBM)
that contains information on the backup job, VMs in the backup, number and structure of backup
REV 1
files, restore points and so on. This metadata file facilitates import of backups and mapping of
backup jobs to existing backups.
Onsite Backup
Backup to Windows or Linux-based Repository
To back up to an onsite Windows or Linux-based repository, you need to deploy a backup proxy
on a server that has access to the source datastore, and point the backup job to this proxy. In this
scenario, the source-side agent is started on the proxy server, and the target-side agent is started
on the Windows or Linux repository server. Backup data is sent from the proxy to the repository
over LAN:
Backup to SMB Share

To back up to an onsite SMB share, you need a Windows-based proxying server that has access to
the SMB share. This can be either the Veeam Backup server or another Windows server added to
the Veeam Backup & Replication console. In this scenario, Veeam Backup & Replication starts the
source-side and target-side agents on the same server. Backup data is sent from the proxy to the
target SMB share over LAN.
Offsite Backup
The common requirement for offsite backup is that one Veeam agent runs in the production site
(closer to the source datastore), and the other agent runs in the remote target site (closer to the
repository). During backup, the agents maintain a stable connection, which allows for
uninterrupted operation over WAN or slow links.
REV 1
Backup to Windows or Linux-based Repository

To perform offsite backup to a Windows or Linux-based repository, you need to deploy a backup
proxy in the production site, closer to the source datastore. In this scenario, the source-side agent
is started on the proxy server, and the target-side agent is started on the Windows or Linux
repository server. Backup data is sent from the proxy to the repository over WAN:
Backup to SMB Share

To back up VMs to an offsite SMB share, you should deploy a backup proxy in the source site and
an additional Windows-based proxying server in the remote site. The SMB repository should be
configured to point to the target-side proxying server. During backup the source-side agent runs
on the source proxy in the production site, and the target-side agent runs on the target proxying
server in the remote site. Backup data is transferred between the backup proxy and the proxying
server over WAN:
Replication
As well as backup, replication is a job-driven process; in many ways, it works similarly to forward
incremental backup:
During the first run of a replication job, Veeam Backup & Replication copies the whole VM
image and registers a replicated VM on the target ESX host.
During subsequent runs of a job, Veeam Backup & Replication copies only incremental
changes, and creates restore points for a VM replica so you can recover your VM to the
necessary state. Every restore point is in fact a usual VMware snapshot.
REV 1
When you perform incremental replication, data blocks that have changed since the last
replication cycle are written to the snapshot delta file next to a full VM replica. The
number of restore points in the chain depends on your retention policy settings.
Replication infrastructure and process is very similar to those used for backup. It includes a source
host, a target host with associated datastores, one or two proxy servers and a repository. The
source host and the target host produce two terminal points between which replicated data is
moved. Replicated data is collected, transformed and transferred with the help of Veeam agents. In
addition to source-side agent and agent hosted on a repository, replication process involves a
target-side agent that interacts with the target host.
The agent hosted on a repository works with replica metadata files.
Important
Although the replica data is written to the target datastore, certain replica metadata must be
located on a backup repository. This metadata is used by the source proxy and thus should be
deployed close to the source host.
1.
When a new replication session is started, the source-side agent operates in the same way
as in backup process.
In addition, in all cases when use of VMware CBT is not possible, the source-side agent
interacts with the agent hosted on the repository to obtain replica metadata in order to
detect what blocks have changed since the previous job run.
2.
Note
Copied blocks of data are compressed and moved from the source-side agent to the
target-side agent.
In on-site replication scenarios, the source-side agent and the target-side agent may run on the
same backup proxy server.
3.
The target-side agent then decompresses replica data and writes the result to the
destination datastore. Veeam Backup & Replication supports a number of replication
scenarios that depend on the location of the target host and will be discussed later in this
guide.
During replication cycles, Veeam Backup & Replication creates the following files for a VM replica:
A full VM replica (a set of VM configuration files and virtual disks). During the first
replication cycle, Veeam Backup & Replication puts these files to the selected datastore to
the ReplicaName folder, and registers a VM replica on the target host.
Replica restore points (snapshot delta files). During incremental replication, Veeam
Backup & Replication creates a snapshot delta file in the same folder, next to a full VM
replica.
Replica metadata (VBK) used to store replica checksums. Veeam Backup & Replication uses
this file to quickly detect changed blocks of data between two replica states. A metadata
file is written to the backup repository.
During the first run of a replication job, Veeam Backup & Replication creates a replica with empty
virtual disks on the target datastore. If the Virtual Appliance mode is applicable, replica virtual disks
are mounted to the backup proxy and populated through ESX I/O stack. This results in increased
writing speed and fail-safe replication to ESXi targets.
To streamline the replication process, you can deploy the backup proxy on a virtual machine. The
virtual backup proxy must be registered on an ESX(i) host that has a direct connection to the target
datastore. In this case, the backup proxy will be able to use the Virtual Appliance transport mode
for writing replica data to target.
If the backup proxy is deployed on a physical server, or use of the Virtual Appliance mode is not
possible for other reasons, Veeam Backup & Replication will use the Network transport mode to
populate replica disk files.
REV 1
Onsite Replication
If the source and target hosts are located in the same site, you can deploy one backup proxy for
data processing and a backup repository for storing replica metadata. This backup proxy must
have access to the source host and to the target host at the same time. In this scenario, the sourceside agent and the target-side agent will be started on the same backup proxy. Replication traffic
will be transferred between the two agents (using low compression).
Offsite Replication
The common requirement for offsite replication is that one Veeam agent runs in the production
site (closer to the source host), and another agent runs in the remote DR site (closer to the target
host). During backup, the agents maintain a stable connection, which allows for uninterrupted
operation over WAN or slow links.
Thus, to replicate across remote sites, you should deploy at least one local backup proxy in each
site:
1.
2.
A source backup proxy in the production site

A target backup proxy in the remote DR site.
The backup repository should be deployed in the production site, closer to the source backup
proxy.
REV 1
Tip
When planning for off-site replication, consider advanced possibilities to reduce the amount of
replication traffic and streamline replica configuration replica seeding, replica mapping, network
mapping and re-IP.
In this scenario, the following connections need to be open between the Veeam Backup &
Replication components:
Important
Veeam Backup server should have access to vCenter server, ESX(i) hosts, and both source
and target backup proxies.
Source backup proxy should have access to the Veeam Backup server, source host, target
proxy, and source vCenter server.
Target proxy should have access to the Veeam Backup server, source proxy, target host,
and target vCenter server.
If you are planning for offsite replication over WAN, it is strongly recommended that you deploy a
proxy server on the target side.
With a proxy server set up on the target side, the data will cross the WAN compressed and will be
uncompressed by the target proxy. Note that you also can seed the replica job by sending your
backup files offsite (using some external media, for example) and then have only incremental job
runs.
It is also recommended that you install an additional Veeam Backup & Replication server in DR site;
there shouldnt be any issues related to the license, since Veeam is licensed by physical CPU socket
of source hypervisor host (where protected virtual machines reside), not by Veeam server. In this
scenario:
Veeam Backup server deployed in the production site will be responsible for backup jobs
and/or local replication
Veeam Backup server in the DR site will control the remote replication jobs.
Thus, in disaster situation all functionality (Failover, Failback and etc.) can be performed by Veeam
Backup & Replication Server in DR site without any problems. Additionally, it may be worth
installing Enterprise Manager to have visibility across two backup servers, and in case of failover
you can manually revoke licenses from the host that is down.
Replication bandwidth estimation has always been a challenge, depending on multiple

factors such as number and size of VMs, change rate (at least daily, per RPO cycle is ideal),
REV 1
RPO target, replication window. Full information about these factors, however, is rarely at
hand. As an option, you may want to setup backup jobs that mirror what you would do
with a replication job, and use the "transferred size" to calculate bandwidth (as this would
be the same amount of data used for replication).
Also, when replicating VMs to a remote DR site (or performing offsite backup), you can
manage network traffic by applying traffic throttling rules or limiting the number of data
transfer connections. See User Guide for more information.
Recovery & Verification

The Veeam vPower NFS service is a Windows service that runs on a Windows-based backup
repository server and enables it to act as an NFS server. vPower NFS allows
Veeam Backup & Replication to mount a compressed and deduplicated backup file as a regular
VMDK file directly to the ESX(i) host via NFS, so ESX(i) hosts get transparent access to backed up
VMware VM images. The vPower technology is used to perform the following tasks:
Recovery Verification (SureBackup)

Instant VM Recovery
Multi-OS File-Level Recovery
Universal Application-Item Recovery (U-AIR)
SureBackup
SureBackup is developed to automate and simplify the backup verification process, one of the
most crucial parts of data management and protection. It is a feature that allows you to start VMs
directly from VM backups in a fenced-off environment and perform backup reliability and
availability testing as a routine part of the backup process.
To perform recovery verification testing, you need to create an application group required to
verify full functionality of backed up VMs, an isolated virtual lab where VMs should be tested, and a
recovery verification job.
An application group is a group of virtual machines that contains VMs running production
applications on which VMs to be verified are dependent. That is, it includes all
components and services that should be started to enable fully functional work of VMs
you want to test.
A virtual lab is an isolated virtual test environment where verified VMs with all
components required for their proper operation are started and tested. A virtual lab is
created using existing resources in your VI environment and ensures secure integrity and
functionality testing for backed up VMs.
A recovery verification job aggregates all settings and policies of a recovery verification
task, such as required application group, virtual lab to be used and backups of VMs that
should be verified in the created environment.
When a recovery verification job runs, VMs from the application group are published and then
started from backups in the required order and remain running while VMs from verified backups
are booted and tested.
REV 1
During verification, a backed up VM image remains in the read-only state all changes that take
place when a VM is running are written to redo log files that are stored on a selected datastore in
the production environment. Once the recovery verification process is complete, the redo logs are
removed.
When performing recovery verification of VM backups, Veeam Backup & Replication runs VMs
directly from backup files without restoring them to a production datastore. This is achieved by
utilizing the vPower NFS service a Windows service that runs on a Windows-based backup
repository server and enables it to act as an NFS server. vPower NFS allows
Veeam Backup & Replication to mount a compressed and deduplicated backup file as a regular
VMDK file directly to the ESX(i) host via NFS, so ESX(i) hosts get transparent access to backed up
VMware VM images.
Recovery
Veeam Backup & Replication allows you to perform both image-level and file-level restores of
backups and replicas. You can restore a virtual machine as a whole to start it on the target ESX
server, recover only VM hard disks, VM files (.vmdk. .vmx and so on) or VM guest OS files and
folders and save them on your local machine. VMs or files can be restored at any of the available
restore points.
Note
The restore process is always performed via the network.
When performing instant recovery, Veeam Backup & Replication creates an independent
temporary copy of a VM in your VMware environment and immediately starts it (if necessary).
You can also use a recovered VM for testing purposes to ensure the VM guest OS and
applications are functioning properly. Instant VM recovery does not require you to extract a
VM from a backup and move it across datacenter it mounts a VM directly from a
compressed backup file on a selected ESX host.
REV 1
The archived image of a VM remains in a read-only state to avoid unexpected modifications.

All changes to a virtual disk that take place while a VM is running are logged to an auxiliary file
on the Veeam Backup server or any datastore you select. These changes are discarded as soon
as a restored VM is removed.
When you perform file-level recovery for Windows OS, the Veeam agent running on the target
host or backup repository mounts the VM file system to the local drive via Veeam's proprietary
driver. After that, you can copy necessary files and folders to your local machine drive and save
them anywhere within the network or simply point any applications to the files and use them
normally. The backup file or replica will remain read-only no matter what you do.
For details on data recovery and verification, please refer toVeeam Backup & Replication Help,
Evaluators Guide and U-AIR Wizards User Guide; you can also view the Veeam Backup &
Replication - How It Works online training video.
REV 1
UNDERSTANDING VEEAM BACKUP &

REPLICATION OPTIONS
Veeam Backup & Replication breaks down the work of backing up VMs into jobs. So, the only way
to determine the best setup and schedule for your Veeam Backup & Replication deployment is to
know your environment, understand various job options and their effect on performance,
scalability, as well as the storage and network infrastructure.
Each job can contain multiple vCenter objects which need to be backed up. They can be as
granular as individual VMs, or as generic as an entire datastore or even the entire datacenter (not
recommended except for very small environments).
Jobs also define the number of retention points for the objects within that job, and, while they can
be run manually, are typically assigned to a schedule.
When determining the best grouping of objects, job modes, and schedules for your jobs, you must
consider a multitude of factors, such as:
Number of VMs to be protected
Preferred object grouping (by OS, by application, and so on)
Amount of data to protected
Amount of changed data per VM
Frequency of protection (RPO)
Number of restore points
Archive requirements (Tape/Offsite)
Performance impact on environment (backup/replication window)
Veeam host resources available
Target storage capacity
Target storage performance
Target storage capabilities (hardware compression/deduplication)
Available bandwidth (for offsite backup or replication)
Now we will discuss related Veeam Backup & Replication options, to help you make a wellgrounded decision on deployment and configuration.
How It Works: Backup Methods

Veeam Backup & Replication offers two backup methods to back up virtual machines: reversed
incremental and forward incremental (default setting). However, before you start planning and
setting up your jobs, consider that whatever backup method you choose for one job (reverse or
forward Incremental, synthetic full, active full, etc.) is not necessarily best for all jobs.
It is strongly recommended that you choose job options individually for each job, considering their
pros and cons, as described later in this section.
REV 1
Reversed Incremental
With this mode, the first run of a backup job creates a full backup of a VM. VM data is copied block
by block, compressed using the selected compression level, and stored in a resulting full backup
file (.vbk). All subsequent backups are incremental, reading only data blocks that have changed
since the last job run utilizing VMwares built-in Change Block Tracking. During the incremental
backup, changes are injected into the .vbk file, modifying this file to reflect the most recent state of
the virtual machines it contains. The process also creates a reversed incremental backup file (.vrb).
This file contains only the data blocks that were replaced during the incremental run. The full
backup file (.vbk) continues to contain the blocks which represent the most recent backup data,
but by overlaying the reversed incremental file (.vrb) Veeam can represent the previous state of the
VM as well since that file now contains the older blocks.
Below are listed some pros and cons of reversed incremental method.
Advantages
Uses absolute least amount of space

Granular retention (e.g. keep exactly 30
restore points)
Allow for forever incremental (no full
backups needed)
Considerations
Requires significantly more I/O on target storage (1x

read, 2x write during backup). Typically slower with
dedupe, especially for high change rate VMs.
New backups cannot be run while restores or virtual
labs are running.
Not recommended for dedupe appliances because
the large .VBK files are changed during every backup,
causing the appliance to re-dedupe the file every
time.
Forward Incremental
When using the Incremental Backup method, a full backup file (.vbk) is created during the first
backup run, exactly like reverse incremental mode. However, subsequent backups save only the
changed blocks since the last performed backup (whether full or incremental) into an incremental
backup file (.vib) next to the full backup.
When using incremental backups, it is required that a full backup be scheduled occasionally to
start a new chain. Veeam offers two ways to create a new full backup.
REV 1
The first option is a feature called Synthetic Full. This feature takes the old full backup and the
incremental backups in the chain to combine them into a new full backup. This method requires
no additional I/O on the source VM, however, it creates significant I/O on the target. This I/O can
sometimes cause an issue when using slower backup targets.
As part of creating a synthetic full, Veeam offers the option to transform the incremental segments
into reverse incremental backups, providing a hybrid approach that allows many of the benefits of
both the reverse and forward incremental methods, at the cost of additional I/O on the target.
A synthetic full can be created on specific days of the week, and as often as every day, or as little as
once a week.
The other option for starting a new backup chain is simply to schedule the job to perform an
Active Full backup at specific intervals. This will, of course, have some impact on the source
storage as it is a standard full backup, which will require retrieving all data from the source storage,
but this can be scheduled for once a week (or once a month, or various other schedules) to meet
the environments retention policy requirements.
Below are some pros and cons of full backup method:
Advantages
Backup files are not changed after they are

written - this is important when writing to a
dedupe appliance
Easier for GFS style staged retention policies -just

copy weekly VBKs and delete unneeded
incremental backups
Works well with dedupe storage - required full

backups are highly deduped with previous fulls
Backups can continue even when earlier backup

files are being used by virtual labs - this is
important if utilizing SureBackup
Consideration
Requires one of the following:
Synthetic Full takes significant

amount of time and I/O on target
storage (2x read, 2x write during
synthetic full operation)
Active Full a periodic full backup

which impacts production. Note
that it uses more raw space (not
typically an issue when used with
dedupe storage)
REV 1
How It Works: Transport Modes

Direct SAN
In this mode, VM data is retrieved directly from Fiber Channel/iSCSI shared storage (Storage Area
Network, or SAN) using the VMware vStorage API for Data Protection. The process of data retrieval
in Direct SAN Access mode includes the following steps:
1.
The backup proxy sends a request to the ESX host to locate the necessary VM on the
datastore.
2.
The host locates the VM and retrieves metadata about the layout of virtual disks on SAN,
or the physical addresses of data blocks, and sends the metadata to the backup proxy.
3.
The backup proxy uses this metadata to copy data blocks directly from SAN.
4.
The backup proxy sends data copied from the datastore to the target.
The SAN mode uses metadata on the layout of virtual disks on SAN to directly read data blocks off
SAN LUN, therefore providing LAN-free transfer of VM data.
Important
VM processing will fail if direct SAN connection is not configured or not available when the job
starts.
Virtual Appliance
This mode utilizes the SCSI hot-add capability of ESX to attach disks of a backed up VM to the
backup proxy VM or to the helper VM (depending on vCenter version you are using).
REV 1
In this mode, VM data is retrieved directly from storage through the ESX I/O stack, instead of going
through the network stack, which improves performance.
Important
The Virtual Appliance mode is recommended and can only be used if the backup proxy is deployed
on a VM running on ESX(i) host.
Please note that the ESX(i) host on which the backup proxy VM resides must have access to the
storage where disks of a backed up VM are located.
Network Mode
This mode can be used with any infrastructure configuration. However, when an alternative
transport mode is applicable, the Network mode is not recommended because of the lowest data
retrieval speed. It is the only applicable mode when the backup proxy is a physical machine and
the host uses local storage. In this mode data is retrieved via the ESX(i) host over the LAN using
NBD (Network Block Device) protocol.
The process of data retrieval in Network mode includes the following steps:
Note
1.
The backup proxy sends a request to the ESX(i) host to locate the necessary VM on the
datastore.
2.
The host locates the VM, copies blocks of data and sends them to the backup proxy over
the LAN.
3.
The backup proxy sends the data to target.
The Network mode is not recommended because of low traffic throughput via the LAN (the copy
of the VM disk usually contains a lot of data). In order to take the load off the LAN,
Veeam Backup & Replication provides two alternative modes: Direct SAN Access and Virtual
Appliance, described above.
Veeam Backup & Replication processes VM disks one by one. If VM disks are located on different
storages (that is, on the SAN and local storage subsystem), Veeam Backup & Replication will use
different transport modes to process VM disks. In such scenario, it is strongly recommended that
you enable the Failover to network mode if primary transport modes fail or are unavailable
option when configuring the mode settings for the necessary backup proxy.
REV 1
How It Works: Retention Policies

Veeam Backup and Replication defines retention as the number of restore points to keep for VMs
within the job. This is not measured by time, but the total number of points (files). It is important
to keep the schedule of the job in mind when selecting the number of points to keep.
Example 1
Assume that you want to keep 30 days of backups, for a job that runs reversed incremental backup
once a day. You can configure 30 restore points and one backup a day.
However, if the administrator manually runs the job four times during the month, in addition to
the schedule, you would end up with 30 restore points in only 26 days. And Veeam Backup &
Replication will delete the oldest reversed increments when the number of backups allowed by the
retention policy is exceeded (that is, on the 27th day, in our example).
Example 2
For a job that is configured to run once a day, in forward incremental mode, with a full backup
once a month, with 14 restore points, Veeam Backup & Replication will take a full backup and then
13 incremental backups before it meets the minimum restore points. However, it cannot delete the
full backup or any of the incremental backups, because they are part of one continuous chain. If
the full backup was deleted, the incremental backups would not be usable, thus not meeting the
retention requirements.
Veeam Backup & Replication will neither delete the original full, nor the month full of incremental
backups until a new full and 13 additional incremental backups are run.
This means that Veeam Backup & Replication will, at times, have as many as 45 restore points (31
days for a full + incremental chain for a month, plus 14 days of the next full and incrementals)
before it can delete the previous months backups as Veeam Backup & Replication is committed
to keeping at least 14 restore points.
De-duplication
De-duplication is applied when backing up multiple virtual machines that have identical blocks
(for example, if virtual machines were created on the basis of the same template), or in the case of
virtual machines with a great amount of free space on their logical disks (known as white space).
Veeam Backup & Replication does not store zero byte blocks or space that has been pre-allocated
but not used. With de-duplication, identical blocks or blocks of free space are eliminated, which
decreases the size of the created backup file. Veeam will also exclude the blocks used for the swap
file, thus reducing the amount of data even further.
If you use data blocks of small size to deduplicate a large backup file, the backup file will be cut
into a great number of data blocks. As a result, Veeam Backup & Replication will produce a very
large deduplication metadata table which can potentially overgrow memory and CPU resources of
your backup repository. Large data blocks produce a smaller metadata table that requires less
memory and CPU resources to process. So, depending on the type of storage you select as a
backup target, Veeam Backup & Replication uses data blocks of different size to process VMs,
which optimizes the size of a backup file and job performance.
There are several storage optimization options available to you when configuring a backup job (or
a replication job):
The Local target (16 TB + backup size) option is recommended for backup jobs that can
produce very large full backup files larger than 16 TB. With this option selected, Veeam
Backup & Replication will use data blocks of 8 MB. Note, however, that this storage
optimization option will provide the lowest deduplication ratio and the largest size of
incremental backup files.
REV 1
The Local target option is recommended for backup to SAN, DAS or local storage. The
SAN identifies larger blocks of data (1024 KB) and therefore can process large amounts of
data at a time. This option provides the fastest job performance but reduces the
deduplication ratio, because with larger data blocks it is less likely to find identical blocks.
The LAN target option is recommended for target NAS and onsite backup/replication. It
provides a better deduplication ratio and reduces the file size due to reduced data block
sizes (512 KB).
The WAN target option is recommended if you are planning to use WAN for offsite
backup/replication. Veeam Backup & Replication will use small data blocks (256 KB), which
will result in the maximum deduplication ratio and the smallest file size, allowing you to
reduce the amount of traffic over the WAN connection.
The various recommended use cases for the different targets above are general rules of thumb, but
there may be situations where using the various modes makes sense outside of these scenarios.
For example, a very high change rate VM may see significant savings from using WAN target mode,
even for local backup or replication, and you may be willing to sacrifice the extra CPU load and
overhead for this benefit.
Compression
Another means of reducing the size of a backup file is compression. Use of compression decreases
the size of created backups but affects duration of the backup procedure. Veeam Backup &
Replication allows you to select one of the following compression levels when configuring a
backup job or a replication job:
None - this option is recommended if you use storage devices with compression and\or
de-duplication tools to store created backups.
Low (Dedupe-friendly in v6.5 UI) this is an optimized compression level for very low
CPU usage and uses a very simple, fixed dictionary. This method can be a good
compromise when using deduplicating storage or WAN accelerators because, while it will
lower the dedupe ratio compared to no compression, it will send less data to the
deduplicating appliance.
Optimal this is the recommended compression level providing the best ratio between
the size of a result file and time of the backup/replication procedure.
Best (Extreme in v6.5 UI) - provides the smallest size of a backup file but will reduce
backup performance if there are not enough hardware resources to keep up. In general,
this mode will create a backup file that is at most 5% smaller that Optimal compression
while using 100% more CPU resources. So, if you intend to use this compression level, it is
recommended that you install Veeam Backup & Replication on computers with modern
multi-core CPU (at least 8 cores per concurrent job is recommended). This method can be
useful for backup/replication across slow WAN links where bandwidth is at a premium
and the higher CPU wont be as impactful.
Indexing and Search

If you have a relatively small number of backups, you may use Veeam Backup Enterprise Manager
that can process indexing data by itself, without Veeam Backup Search installed. In this case, no
content index will be generated, which will allow you to save on disk space for storing index
content. However, if you are planning to use the file search feature for a large number of VM
backups in your backup infrastructure, it is recommended that you configure at least one Veeam
Backup Search server and add it to Veeam Backup Enterprise Manager.
So, before you set up indexing options for your backup jobs, consider the following:
REV 1
Though use of the backup content index streamlines the search process, the content
index itself can require significant space on disk.
If you choose to implement search without content index (that is, no Veeam Backup
Search installed), you will save on disk space, but this method can result in a slower search
process.
The capacity of a search server is limited and depends on the type of search server you
plan to use. If you have a large number of backup servers and/or require storing index
documents for a long period of time, you may want to deploy a number of search servers.
In this case, the query processing and indexing load will be automatically spread across all
deployed search servers.
To coordinate proper indexing activities, Veeam Backup & Replication deploys an

executable inside a VM. This small executable is used only during indexing procedure and
is removed immediately after the processing is finished, producing minimal impact on VM
performance and stability. However, if you need to avoid any extra load on some of your
VMs, you can exclude them from indexing.
REV 1
DEPLOYMENT SCENARIOS
Veeam Backup & Replication can be used right out of the box in virtual environments of any size
and complexity. The architecture of the solution supports on-site and off-site data protection,
operations across remote sites and geographically dispersed locations. This section describes
common deployment scenarios to help you better plan your backup infrastructure layout,
depending on your environment size, structure, geographical and/or organizational boundaries,
and data protection approach.
Small-size Environment or Pilot: Simple

Deployment
This scenario assumes you back up and replicate only a small number of VMs or evaluate
capabilities of Veeam Backup & Replication. For that, you can use a simple deployment scenario:
install one instance of Veeam Backup & Replication on a physical or virtual Windows-based
machine.
Simple deployment implies that the Veeam Backup server fills several roles:
It functions as a management point, coordinates all jobs, controls their scheduling and
performs other administrative activities.
It acts as the default backup proxy for handling job processing and transferring backup
traffic. All services necessary for the backup proxy functionality are installed on the Veeam
Backup server locally.
It is used as the default backup repository.
In a simple deployment scenario all data is handled and stored on the Veeam Backup server locally.
REV 1
Example 1: All-in-one Physical
In a direct SAN environment, physical hardware with direct FC or iSCSI connectivity is the
recommended option for maximum performance.
Example 2: All-in-one Virtual
Virtual hardware, however, can achieve acceptable performance in almost all environments, so this
can be the best option in some cases. Installing Veeam Backup & Replication on a virtual machine
will enable you to use the Virtual Appliance transport mode, allowing for LAN-free data transfer.
This scenario may be appropriate for development clusters or smaller special-purpose

environment within your infrastructure (for example, POC environment).
Medium-size or Large-scale Environment:

Advanced Deployment
For medium-size or large-scale environments, it is recommended to use the advanced deployment
scenario which moves the backup workload from Veeam Backup server to dedicated backup
proxies and backup repositories.
The essence of the advanced deployment is that the backup proxy takes off a part of Veeam
Backup server activities namely, it collects and processes data and moves backup traffic from
REV 1
source to target. In addition, the Veeam Backup server no longer acts as a storage location the
backup proxy transports VM data to the backup repository which is the location for keeping
backup files, VM copies, metadata and so on. The Veeam Backup server in this scenario functions as
a manager for backup proxies and repositories.
You just add servers to Veeam Backup & Replication and assign proxy and repository roles to them.
Veeam Backup & Replication will automatically install light-weight components and services onto
these servers. Backup proxies do not require SQL all settings are stored centrally, within the SQL
database used by the Veeam Backup server.
Example 1: Virtual Veeam Backup server, virtual proxy
Deploying Veeam Backup & Replication server on a VM allows you to leverage vSphere features
such as High Availability and vMotion. For peculiarities of physical and virtual proxies, please refer
to Physical or Virtual? section of this guide.
With the advanced deployment scenario, you can easily meet your current and future data
protection requirements. You can expand your backup infrastructure horizontally in a matter of
minutes to match the amount of data you want to process and available network throughput.
Instead of growing the number of backup servers or constantly tuning job scheduling, you can
install multiple backup proxies and repositories and distribute the backup workload among them.
REV 1
Example 2: Backup with multiple virtual proxies
When using multiple proxies, Veeam Backup & Replication provides for dynamic distribution of the
backup traffic among these proxies:
A job can be explicitly mapped to a specific proxy.
Alternatively, you can let Veeam Backup & Replication choose a proxy. In this case,
Veeam Backup & Replication will check settings of available proxies and select the most
appropriate one for the job.
The advanced deployment scenario can be a good choice for backing up and replicating off-site.
You can deploy a backup proxy in the production site and another one closer to the backup
repository.
Example 3: Off-site CIFS and multiple proxies
When a job is performed, backup proxies on both sides establish a stable connection, so this
architecture also allows for efficient transport of data over a slow network connection or WAN.
To regulate backup load, you can specify the maximum number of concurrent tasks per
proxy and set up throttling rules to limit proxy bandwidth. The maximum number of
concurrent tasks can also be specified for a backup repository; additionally, you can define
combined ingestion rate for it.
Another advantage of the advanced deployment scenario is that it contributes to high

availability: jobs can migrate between proxies if one of them becomes overloaded or
unavailable.
REV 1
Example 4: Scaling for Production and DR sites

Another option is to have one Veeam Backup server deployed in production site to be responsible
for backup jobs and/or local replication, and another Veeam Backup server installed at the DR site
for the remote replication jobs:
Thus, in disaster situation all operations can be performed by Veeam Backup Server in DR itself
without any problems.
Note
Typically, it is recommended to deploy one proxy for backup & restore, and another for replication
and failover.
With Veeams restore capabilities to be used efficiently, you can also think of deploying a virtual
proxy per cluster for hot-add restore.
Large, Distributed Environment: Distributed

Deployment
The distributed deployment scenario is recommended for large geographically dispersed virtual
environments with multiple Veeam Backup servers installed across different sites. These backup
servers are federated under Veeam Backup Enterprise Manager:
REV 1
Veeam Backup Enterprise Manager collects data from Veeam Backup servers and enables you to
run backup and replication jobs across the entire backup infrastructure through a single pane of
glass, edit them and clone jobs using a single job as a template. It also provides reporting data for
various areas for example, all jobs performed within the last 24 hours or 7 days, all VMs engaged
in these jobs and so on.
Besides, using Veeam Backup Enterprise Manager simplifies tracking license usage and license
updates across multiple Veeam Backup Servers. You can install one license on the Veeam Backup
Enterprise Manager server and it will be applied to all servers across your backup infrastructure.
REV 1
INTERACTION WITH VSPHERE VIRTUAL

ENVIRONMENT
Veeam Backup & Replication interacts heavily with the vSphere infrastructure, and much of the
success of an implementation depends on performance and stability of this environment. In this
section we will discuss those interactions and note the items that should be considered for a
successful implementation.
While it is possible to use Veeam by connecting directly to the ESX(i) hosts, this section assumes a
vSphere environment with at least one vCenter server and that the Veeam Backup and Replication
server is integrated at the vCenter level as this is the best practice configuration in almost all use
cases.
vCenter Server
One of the most critical components of any vSphere environment is the vCenter server. This server
provides a single view of the entire virtual environment, and a central point of management.
Veeam Backup & Replication communicates with vCenter for many operations, so fast, stable
communications between Veeam Backup & Replication and the vCenter server are critical to
achieving a stable backup environment. Below are listed some of the important factors that should
be considered.
Problems with connectivity to vCenter are one of the top reasons for failed Veeam jobs, but having
a well performing vCenter server with reliable connectivity will mitigate this issue and provide a
strong backbone for a reliable backup infrastructure.
Health
The vCenter server must be reliable and always available when backup jobs are running. It must be
able to answer queries and perform actions in a reasonable amount of time. If the vCenter server
performs poorly during normal operations, this should be corrected prior to implementing Veeam
Backup & Replication.
Capacity
For larger environments, with many concurrent jobs, especially jobs that run at short intervals,
such as Near-CDP, the load on the vCenter server can be significant. The vCenter server must be
able to handle this increased transactional workload to prevent random job failures due to
command timeouts.
Connectivity
The Veeam Backup & Replication server must have reliable network connectivity to the vCenter
server. It is generally suggested that the Veeam Backup & Replication server be placed in close
logical proximity to the vCenter server, but this is not always the best deployment option. In cases
where the Veeam server and vCenter must be deployed across a distance, the only real
requirement is that this connection be reliable.
REV 1
Maintenance
When maintenance is being performed on the vCenter server, best practice would dictate that all
Veeam Backup and Replication jobs should be idle, and Veeam Backup Service should be stopped.
This includes applying Windows updates, vCenter patches and upgrades, or any maintenance that
would require the vCenter service to be restarted or the system rebooted.
Impact of Snapshot Operations

Veeam Backup & Replication leverages the vSphere functionality for snapshots to create backups
of VMs.
When Veeam Backup & Replication begins the backup of a VM, it communicates with vSphere to
request a snapshot of the VM, and after the backup of the VM is complete, Veeam requests that the
snapshot be removed. The creation and removal of snapshots in vSphere creates a significant
impact on the environment that must be taken into account. Here we will discuss the various
factors that should be considered regarding this process, and recommend techniques to minimize
the impact of snapshot operations.
As a concept, vSphere snapshots are a simple technology. A VM generally contains at least one
virtual disk, which is represented by a VMDK file. When a snapshot is taken, VMware continues to
read blocks from the file as normal, however, for any new blocks that are written to the disk, these
writes are redirected to a new thin VMDK file called the delta file. Since the original VMDK file is
only being used for reads, it provides a consistent view of the blocks that made up the VM at the
time the snapshot was taken - this allows Veeam Backup & Replication to read this based disk as a
consistent image for backup and replication. When the snapshot is removed, the blocks that were
written to the delta file are read and written back into the original VMDK, and finally the delta file is
discarded.
As with many things in technology, although the concept is simple, the actual implementation is a
little more involved. The following is a quick look at the impact of various operations on the VM
and underlying infrastructure.
Snapshot Creation
The actual operation of creating a snapshot generally has only a minor impact: the snapshot file
has to be created, and there is a very short stun of the VM. This is generally short enough so that
it is rarely an issue except for the most time-sensitive applications.
Note
For normal snapshot operation, try to keep the size of the vmdk disk under 1.98 TB, otherwise
snapshot creation may fail due to known VMware limitations. For details, please refer to VMware
Knowledge Base article 1012384.
Snapshot Open
Simply having a snapshot open for a running VM involves some performance penalty on the VM,
the ESX(i) host and the underlying storage. The host has to track the I/O, split writes to the
snapshot file, update the snapshot file metadata. This extra overhead, in turn, impacts the host
(primarily, with slower I/O). This is generally most notable for VMs with significant write load, and
has less impact on read performance.
From a storage perspective, VMs running with an open snapshot require the additional space to
store the snapshot data, and additional I/O load on the datastore. Once again, this is generally
more noted on systems with significant write I/O load.
Note
Also, remember that vMotion cannot be performed for VMs with an open snapshot.
REV 1
Snapshot Removal
This is the most impactful step from a performance perspective. I/O load increases significantly,
due to the extra R/W operations required to commit the snapshot blocks back to the original
VMDK. This eventually leads to the VM stun required to commit the final bits of the snapshot. The
stun is typically a short pause usually only a few seconds or less, where the VM is unresponsive
("lost ping") while the very last bits of the snapshot file are committed. VMware uses a rolling
snapshot method to minimize the impact and duration of the stun as outlined below:
1.
The ESX(i) host takes a second, helper snapshot to hold new writes.
2.
The ESX(i) host reads the blocks from the original snapshot and commits them to the
original VMDK file.
3.
The ESX(i) host checks the size of the helper snapshots, if over the threshold size,
repeat step 1.
4.
Once all helper snapshots are determined to be under the threshold size, stun the
VM and commit the last bits of the snapshot.
This stun period can be less than 1 second for small VMs with light load, or several
seconds for larger VMs with significant load. To external clients this small stun simply
looks like the server is busy and thus might delay a response for a few seconds.
However, applications that are very sensitive to delays may experience issues with
this short period of unresponsiveness.
Please refer to VMware Knowledge Base article 1002836 for explanation of snapshot removal
issues.
How to Mitigate?
General Recommendations
To mitigate the impact of snapshots, consider the recommendations that follow:
Minimize the number of open snapshots per datastore: multiple open snapshots on the
same datastore are sometimes unavoidable, but the cumulative effect can be bad. Keep
this in mind when designing datastores, deploying VMs and creating backup and
replication schedules. Leveraging backup by datastore can be useful in this scenario.
Consider snapshot impact during job scheduling: when possible, schedule backups and
replication job during periods of low activity. Leveraging the Backup Window
functionality can keep long running backups from running during production.
Use the vStorage APIs for Array Integration (VAAI) where available. VAAI can offer
significant benefits:
o
Hardware Lock Assist improves the granularity of locking required during

snapshot growth operations, as well as other metadata operations, thus lowering
the overall SAN overhead when snapshots are open.
VAAI in vSphere 5.x offers native snapshot offload support and should provide
significant benefits once vendors release full support.
Design datastores with enough IOPS to support snapshots. Snapshots create additional
I/O load and thus there must be enough I/O headroom to support the added load of
snapshots. This is especially important for VMs with moderate to heavy transactional
workloads.
Allocate enough space for snapshots. According to the best practices, it is strongly
recommended to have 10% free of datastore in case of general VM, and, at least, 20% in
case of VM with high change rate (SQL server, Exchange server, and others).
REV 1
Note
Sometimes, VMs residing on NFS storage may become unresponsive during snapshot removal (this
may happen under certain conditions described in VMware KB article 2010953). As the case is
recognized as VMware known issue, it is recommended that you contact VMware support. As a
work-around, for large VMs you can try using dedicated backup proxy on the same ESXi host
where you have your VMs; for smaller VMs, you can switch to network mode.
Tips for vSphere 5.0 and later

Creating snapshots on these vSphere versions will cause the snapshot files to be created on the
same VMFS volumes as the individual VM disks. This at least means that a large VM, with multiple
VMDKs on multiple datastores, will spread the snapshot I/O load across those datastores, but it
actually limits the ability to design and size a dedicated datastore for snapshots, so this has to be
factored in to the overall design.
Allocate enough space to hold snapshots. Since vSphere 5.0 puts the snapshot VMDK on
the same datastore with the parent VMDK, if a VM has virtual disks on multiple datastores,
each datastore must have enough space to hold the snapshots for their volume. You must
take into consideration the possibility of running multiple snapshots on a single datastore.
workloads.
Tips for vSphere 4.1 and earlier

With vSphere 4.1 and earlier, snapshots are, by default, created on the same datastore which
contains the VM configuration file (.vmx file). For many organizations, this is also the disk on which
the entire VM resides. When both the original VMDK, and the snapshot VMDK exist on the same
datastore, it significantly increases the I/O load on that set of spindles, especially during snapshot
commit. This is true even if the VM has multiple virtual disks on multiple datastores, so a SQL server
with 8 VMDK files spread across 8 datastores, will still create all of its snapshot files on the datastore
that contains the VM configuration file. This means that, while the snapshots are open, all writes
would be going to the same datastore, a critically important design consideration.
So, below are version-specific recommendations for vSphere 4.1 and earlier:
Allocate enough space to hold snapshots. The volume that will contain your snapshots
must have enough space to hold the snapshots for the length of a full backup, as well as
enough overhead to hold the helper snapshots while the Veeam snapshot is removed.
You must take into consideration the possibility of running multiple snapshots on a single
datastore.
Dedicate a datastore to snapshots this is especially useful for large VMs. Many
companies choose to have a configuration datastore, which stores nothing but VM
configuration files and is sized to store snapshots. This volume should be sized both for
space, and for the required IOPS. Leveraging very low latency storage, such as dedicated
SSD, or hybrid SATA/SAS/SSD volumes, can significantly reduce the impact of both
running a VM with an open snapshot, and reduce the time of committing that snapshot
by 50-75%.
-OR-
Create an OS datastore: if there are not enough resources to dedicate an entire datastore
just for snapshots, consider dedicating a datastore specifically to storage OS volumes, VM
configuration, and snapshots. OS volumes typically have relatively low I/O requirements
and minimal change during backups so their commit times are low. Dedicating fast disks
to these volumes will help mitigate snapshot impact, while also improving boot speed
and patch application times for the OS.
REV 1
workloads.
See also Planning for the Source section of this guide.
Security
When connecting Veeam to the vCenter infrastructure you must supply credentials which the
Veeam Backup & Replication server will use when communicating with the vCenter server. The
features that Veeam provides, such as backup, restore, replication, and SureBackup, interact with
vSphere at a fundamental level. Thus, certain permissions are required to take snapshots, create
VMs, datastores, and resource groups. Because of this level of interaction, it is generally
recommended that Veeam Backup & Replication use an account with full administrative
permissions.
However, in some environments providing full administrative permissions is not desirable or
allowed. For those environments, Veeam has identified the minimum permissions required for the
various functions within the software. Please review the permissions required as defined in the
Granular Permissions document and configure the account used by Veeam Backup and Replication
to meet these requirements.
You can also leverage security to restrict the view of the environment that a Veeam Backup &
Replication server can see. This can have multiple benefits beyond security in that it lowers the
time required to parse the vCenter hierarchy and reduces to memory footprint required to cache
this information. However, care must be taken when attempting to use this level of restriction, as
some permissions must be provided at the very top of the vCenter tree.
For detailed description of accounts, rights and permissions required for Veeam Backup &
Replication operation, you can refer to the Required Permissions document.
Network Connectivity
Proper network connectivity between the various infrastructure components is required. Any
firewalls that exist between the various roles may require ports being opened to allow for proper
communications. The following sections provide an overview of the required IP connectivity
between various Veeam components, including description of ports and their usage:
Veeam Backup Server Connections

The following table describes network ports that must be opened to ensure proper
communication of the Veeam Backup server with other infrastructure components.
From
To
vCenter Server
Veeam
Backup server
ESX(i)
server
Protocol
Port
HTTPS
443
HTTPS
443
TCP
902
TCP
22
Notes
Default VMware web service port that
can be customized in vCenter
settings.
Default VMware web service port that
can be customized in ESX host
settings. Not required if vCenter
connection is used.
VMware data mover port.
Default SSH port used as a control
channel, only for jobs with a full ESX
target with the service console agent
enabled.
REV 1
From
To
Protocol
Linux
server
Windows
server
Port
TCP
22
TCP
UDP
135,
137139,
445
TCP
6160
TCP
6162
TCP
6161
TCP
UDP
111
2049+
1058+
Linux
server
Veeam Backup
server
TCP
25005000
Windows
server
Veeam Backup
server
TCP
25005000
Notes
Port used as a control channel from
the console to the target Linux host.
Ports required for deploying
Veeam Backup & Replication
components.
Default port used by the Veeam
Installer Service.
Transport Service.
vPower NFS Service.
Standard NFS ports.
Note: If ports 2049 and 1058 are
occupied, the succeeding port
numbers will be used).
Default range of ports used as
transmission channels for jobs
writing to Linux target. For every TCP
connection that a job uses, one port
from this range is assigned.
transmission channels for jobs
writing to Windows target. For every
TCP connection that a job uses, one
port from this range is assigned.
Backup Proxy Connections

The following table describes network ports that must be opened to ensure proper
communication of backup proxies with other infrastructure components.
From
To
Protocol
Port
Notes
Communication with VMware Servers

vCenter
Server
VMware Backup
Proxy
ESX(i)
server
HTTPS
443
Default VMware web service port

that can be customized in vCenter
settings.
TCP
902
VMware data mover port.
443
Default VMware web service port

that can be customized in ESX host
settings. Not required if vCenter
connection is used.
HTTPS
Communication with Backup Repositories
VMware Backup
Proxy
Linux
server
TCP
22
Shared folder
CIFS (SMB)
share
TCP
UDP
135,
137-139,
445
Port used as a control channel from

the backup proxy to the target
Linux host.
Ports used as a transmission
channel from the backup proxy to
the target CIFS (SMB) share.
REV 1
From
To
Protocol
Port
Linux
server
VMware
Backup Proxy
TCP
2500-5000
Windows
server
VMware
Backup Proxy
TCP
2500-5000
Notes
transmission channels for backup
jobs. For every TCP connection that
a job uses, one port from this range
is assigned.
transmission channels for backup
jobs. For every TCP connection that
a job uses, one port from this range
is assigned.
Communication with Backup Proxies
VMware Backup
Proxy
VMware
Backup Proxy
TCP
2500-5000

transmission channels for
replication jobs. For every TCP
connection that a job uses, one
port from this range is assigned.
REV 1
Veeam Backup Enterprise Manager Connections

If you plan to install Veeam Backup Enterprise Manager in your deployment, refer to the following
table describing network ports that must be opened to ensure proper communication of Veeam
Backup Enterprise Manager with other components:
From
To
Protocol
TCP
Veeam Backup
Enterprise
Manager
Veeam
Backup
Server
Browser
9392
9393
TCP
2500
to
2600
Microsoft
Search Server
IIS Extension
Port
Veeam
Backup
Enterprise
Manager
IIS extension
TCP
9395
TCP
9394
TCP
9393
HTTP
9080
Notes
Default port used by Veeam Backup
Enterprise Manager for collecting
data from Veeam Backup servers.
Can be customized during Veeam
Backup & Replication installation.
Backup Catalog Data service for
catalog replication. Can be
customized during Veeam Backup
& Replication installation.
Ports used by the Veeam Backup
Catalog Data service for replicating
catalog data.
Backup Search service integration
component. Can be customized
during Veeam Backup Search
installation.
Default port used by IIS extension
to communicate with Enterprise
Manager. Can be customized
during Enterprise Manager
installation.
Default port used to enable file
search. Can be customized during
Enterprise Manager installation.
Default ports used to communicate
with the website. Can be
customized during Enterprise
Manager installation.
REV 1
RESOURCE PLANNING AND OPTIMIZATION

Generally, to estimate the resources required for your Backup & Replication infrastructure you have
to answers to the following questions:
How many VMs?
How much data?
What is the frequency of backup?
What is the backup window, that is, how quickly do I need to get the back done?
The following diagram illustrates the flow of data through Veeam Backup and Replication
environment and points at which Veeam Backup & Replication collects bottleneck statistics:
Here:
Source (1) refers to the storage from which the backup data is being read. Performance
here can be affected by:
o
Type of disks (SATA vs SAS)
Transport (FC, iSCSI, NFS, or direct)
vStorage API method (Direct SAN, Hot-add, or NBD)
See Planning for the Source to learn more.
Proxy (2) refers to the server that is reading and processing the data. This server performs
the compression and deduplication of the data and thus requires significant CPU
resources and memory throughput. In general, this system should be as close to the
source storage as possible.
Network (3) refers to the communication between the proxy server and the target. For
backup jobs the target is a repository, while for replication job the target is another proxy
server. In some cases, generally smaller environments, the proxy and target may be on the
same server.
Target (4) refers to the system that received the compressed/deduped backup data and
writes it to the target storage. This can be either a repository or a proxy based on whether
the job is a backup or replication job. In general, this system should be as close to the
target storage as possible.
The primary factors that impact the performance of Veeam Backup & Replication are CPU resources
as well as both source and target throughput. You can have the latest 16 core CPU system with GBs
of memory, but if the backup target is a 4-drive RAID5 NAS via a 1Gb CIFS share, your backup
performance isnt going to be very good. So, to achieve the most efficient backups, each phase in
this data flow must be assigned the appropriate resources.
Planning for the Source

Verifying the capacity of your source environment is important in assuring that backups can run
without negatively impacting the performance of the running systems. The source refers to the
storage that is used by your virtualized environment, whether it be shared SAN, NFS, or directly
attached to your virtual hosts. Overlooking the impact that will be caused by the taking and
REV 1
committing of snapshot data (discussed in Impact of Snapshot Operations section above), as well
as the added impact of data transfers, can lead to significant degradation of the production
environment during backups and cause backups to take longer than required.
When a virtual backup is taken, a snapshot must be created of the VM. Its the snapshot data that is
copied by Veeam Backup & Replication to the backup storage. However, while that backup is
taking place, the VM is still running, thus changes to the disk must be written to a temporary
location, the snapshot file. For lightly loaded VMs this is unlikely to be a major issue, but for VMs
with moderate to heavy transactional load this snapshot can grow quickly.
Thus, you must verify that your source storage can handle both the growth of your snapshots, and
the extra I/O load that is created by the snapshots, as well as the actual backup I/O. This impact is
most notable during full backups, since this involves transferring significant amounts of data and
requires snapshots to be held open for longer periods of time.
As Veeam Backup & Replication leverages the hypervisor to create snapshots, the impact of
snapshots can be estimated prior to implementation by manually taking snapshots via the
management console and observing their growth and impact.
Tip
Veeam uses built-in intelligence to check if there is enough free space on datastore before starting
the backup:
Veeam Backup & Replication will not attempt to take VM snapshot if free space on
datastore hosting snapshot file is less than 2 GB.
You will receive a warning message when the free space on production datastores
reaches 10 GBs.
For vSphere 4.1 and earlier, VMs with multiple virtual disks spread across multiple datastores store
all snapshot files on a single datastore. By default, the snapshot files are created on the same
datastore with the VM configuration file, however, this can be manually redirected using the
workingDir parameter (will be explained later in this section). For VMs where I/O load has been
intelligently balanced across multiple datastores this creates unique challenges.
Example
The table below represents an Exchange 2010 server with the OS and Application volumes stored
on a VMFS volume, while the Exchange logs and mailbox stores are using virtual raw device
mappings individual SAN volumes with spindle counts allocated to handle the required load.
Disk description
Size
Datastore
name
RAID level
Spindles
IOP profile
VM configuration
& OS (C:\)
40GB
DS_OS
(VMFS)
Light R/W
Application (D:\)
40GB
DS_OS
(VMFS)
Light R/W
Logs1 (E:\)
100GB
DS_LOGS1
(vRDM)
10
Heavy Write
Logs2 (F:\)
100GB
DS_LOGS2
(vRDM)
10
Moderate
Write
Mailstore1 (G:\)
500GB
DS_MBX1
(vRDM)
10
12
Heavy R/W
Mailstore2 (H:\)
500GB
DS_MBX2
(vRDM)
10
12
Moderate
R/W
With the default configuration of vSphere version earlier than 4.1, when you take a snapshots of
this VM, all writes for the entire VM will be redirected to the DS_OS volume. Where previously this
write load was spread across 46 disk spindles, after the snapshot, almost all write loads are directed
toward the 6 spindles of the DS_OS datastore.
REV 1
This will have a significant performance impact on the VM. Whether this impact is noticeable to
end users, depends on how busy the VM is and how close to the I/O capacity of your datastore you
are during the time the snapshot is open.
To compensate for this issue on busy VMs, you must make sure that snapshots are created on
volumes that can handle this extra I/O load.
To do this with vSphere 4.1, you can:
Create one or multiple dedicated, high-performance datastores to hold VM configurations

as well as snapshots. These datastores should have very high I/O capabilities. Customers
with very high transaction loads find that the use of SSD or hybrid SAS/SSD datastores can
significantly minimize the impact of snapshots.
Redirect snapshots using the workingDir parameter. With this parameter, you can direct
snapshots for a VM to a volume other than the volume which holds the configuration file.
The disadvantages to this method are that the VM must be powered off for the changes to
take effect, and the parameter will get reset if vMotion is used to relocate the VM. See
VMware KB article 1002929 for details.
For vSphere 5.0 and later, snapshots for each virtual disks are created on their individual datastore.
The critical thing to keep in mind here is that each datastore will have to keep enough free space
to hold the snapshot growth for the duration of the backup. For this reason, Veeam recommends
that datastores should be limited to no more than 80% utilization to leave space available for
snapshot operations.
Note
In ESXi 5.x, the workingDir parameter still exists but is only used to specify the location of the
snapshot .VMSN file. To revert to the pre-ESXi 5.0 way of storing snapshots in the directory
specified by the workingDir parameter, the new snapshot.redoNotWithParent parameter must
be added to the virtual machine's .VMX file, as described in VMware KB article 2007563. This can be
of use for large volumes.
Planning for Proxies

The proxy servers are the real workhorse of the Veeam Backup & Replication, especially CPU
resources. In general, assuming default compression options, it is recommended that there be 2
CPUs available for every active job.
For physical servers that would be 2 cores for every job, while for virtual servers that is 2
vCPUs for every active job.
For virtual proxies it is best to allocate at least 4 vCPUs to leave resources available for
other server functions.
For memory sizing, you can assume that the Veeam agent will use its maximum memory (1.7GB),
and then give some headroom to be safe. Therefore, requirement is 2GB per concurrent process as
a minimum.
Physical or Virtual?
Choosing between physical and virtual proxies is always a topic of discussion, although with
Veeam Backup & Replications distributed architecture you are free to choose both.
For maximum performance in a direct SAN environment physical hardware with direct FC or iSCSI
connectivity is difficult to beat, and, where available, is ideal. However, virtual hardware can
achieve acceptable performance in almost all environments and can the best option in some
environments.
There are several advantages and disadvantages to consider when decided between physical and
virtual servers.
REV 1
Physical server
Pros
Cons
Provides best throughput, especially when

using direct SAN access for FC and iSCSI
storage
Multi-core processors can run more
simultaneous jobs meaning less proxies to
manage
No added CPU load on virtual infrastructure
Easier and more robust recovery from
catastrophic failures involving failed virtual
infrastructure
Target storage can be attached directly to
physical servers
Requires investment in additional

hardware
Requires more complex storage setup
for direct SAN access and ongoing
configuration as storage environment
evolves
Provides limited advantages for NFS
environments
Virtual server
Can use existing virtual machines

Leverages existing infrastructure
Requires no additional hardware
Generally the highest performance option for
NAS and DAS datastores
Simpler setup and configuration
Virtual proxies are limited by vCPU

resources
Multiple proxies in the infrastructure
can have significant impact on host
resources
Generally requires more proxies to
achieve the same throughput as
physical
Target storage typically must be
accessed via network which can be a
potential bottleneck
Deciding between a physical and virtual deployment is really about understanding your priorities
and available resources. In many cases, a mix of strategies may make sense.
A physical proxy might be ideal for backing up a production cluster with lots of storage, while
virtual proxies may be more appropriate for development clusters, remote offices, or smaller
special purpose environment within your infrastructure.
With the distributed model of Veeam Backup and Replication, you are free to build your backup
infrastructure fully virtual, fully physical, or any combination that you see fit while still providing
full protection to your environment.
Sizing
The following recommendations are provided as starting points; significant variation can occur
based on environmental factors. We assume typical environments with average change rates of 25% daily and an 8 hour backup window.
Virtual proxy one 4 vCPU VM for every 100 VMs or 10TB of data. This assumes two jobs
each producing approximately 50MB/s each for full backups.
Physical proxy one 16 core physical system for every 400 VMs or 40TB of data. This
assumes physical SAN connectivity and 8 concurrent jobs each producing ~100MB/s each
for full backups.
Note that this means you must have bandwidth to the physical server to achieve this level of
performance, high-speed interconnects such as 8Gb Fiber Channel or 10Gb Ethernet is highly
recommended.
Important
Deploying test proxies and running jobs to measure throughput can help determine more
accurate numbers for the specific environment.
REV 1
Choosing Transport Mode
For physical proxies, use SAN mode; remember that SAN mode requires the physical server to
be provisioned with access to the storage subsystem, either via Fiber Channel or iSCSI.
For virtual proxies, use Hotadd mode; remember that Hotadd mode requires that the proxy
server be located on a VM in the same cluster/host as the VM you are backing up.
Use network mode only when other modes are not available.
If a datastore cannot be accessed by Direct SAN or HotAdd mode by any proxy, then the system
will use Network mode to retrieve the VM disks via the ESXi management interface. When using
Network mode, Veeam Backup & Replication attempts to locate a proxy that is on the same subnet
as the ESXi management interface to reduce the risk of crossing slow, layer-3 networks. In this
mode, the VM data is transferred over the IP management network so it is important that this
network has the ability to handle sustained high-speed data transfer without interfering with
normal management traffic.
Important
If you plan to deploy proxy server(s) on existing VM(s), and then such virtual proxy is set up to
backup or replicate itself, be aware that CBT will get disabled on it, and the job will automatically
failover to Network mode.
This might impact performance (especially noticeable for bigger VMs), so it is recommended that
you use another proxy server to back such VM(s) up.
Planning for Repositories

Repositories must be sized big enough for storing backups, and also for performing the I/O
required to complete backup jobs in an appropriate timeframe.
Its easy to fall into the trap of simply buying the biggest, cheapest storage and throwing your
backups there. While this will work, it will limit the backup and recovery options available because
backup is all about I/O.
Veeam Backup & Replication leverages disk storage to store its backups. When preforming a
reverse incremental backup, every changed block read from the source storage will create 3 I/Os
on the target. In case of large, slow disk this will cause backup performance to suffer. You can
compensate for this performance by using incremental backup, but this comes at the cost of
requiring periodic full backups and increased storage space. Faster target disks can also take better
advantage of advanced Veeam Backup & Replication features like SureBackup and Instant Restore.
Understanding the Impact of IOPS on Backup Performance

While disk throughput is typically measured in MB/s, this is not a very meaningful performance
measurement for Reverse Incremental backups, or other loads (such as SureBackup or Instant
Restore). For those functions, a far more accurate measurement is Random IOPS - the number of
random Read or Write operations a device can perform each second. This is largely impacted by
the physical constraints of the disk, things like head movement time and rotational latency. In
general, the faster a disk spins, the higher its IOPS measurement is. The table below lists typical
IOP performance for common disk used in datacenters.
Device
IOPS
7,200 RPM SATA
~75-100 IOPs
10,000 RPM SATA/SAS
~125-150 IOPs
15,000 RPM SAS
~175-210 IOPs
REV 1
So, while a 7,200 RPM SATA disk may be able to sustain 50MB/s or more in sequential reads or
writes, its only capable of 75-100 IOPs per second. The typical read or write request from Veeam
Backup & Replication will be fairly large, averaging 128-256K, but even if we use these larger
numbers you can quickly see how IOPs will restrain performance.
Assuming a 4-drive RAID 5 array with 7,200 RPM SATA disk, the total IOP capacity is ~350 IOPS at
best, multiplied by the largest read/write I/O size of 256KB, and the array can perform
approximately 90MB/s of random I/O in the best of cases. This looks sufficient enough, until you
realize that for every MB of data read from the source, Veeam will have to perform 3 I/Os on the
target storage for reverse incremental - as the new data is written to the .VBK file, old blocks are
read from the .VBK, and the old blocks are written to the .VRB file. This effectively cuts the backup
throughput to 30MB/s.
Even this is likely acceptable for VMs with low change rate, but VMs that get many, random
changes, such as Exchange and SQL, will likely see very poor performance with such a target.
The Cost of Forward Incremental

You can compensate for limited target I/O by making use of incremental backups, which perform
streaming write I/O and thus are not as affected by the limited IOPs available from the target
storage. However, keep in mind that relative to reverse incremental, forward incremental can
require significantly more space for similar retention periods, like shown in the example below.
Example
ACME Corp needed to back up 100VMs, with a total size of 10TB (an average of 100GB per VM).
They decided to buy a simple NAS storage device with 6x2TB SATA drives giving them ~10TB of
usable RAID5 storage for backups but real world IOPs topped out around 300-350IOPs.
After compression and deduplication, the original .VBK file was 2.5TB, and nightly backups were
averaging around 100GB each. This meant that, using reverse incremental, keeping 30 days of
backups would only require approximately 5.5TB of space, easily small enough to fit on the target
storage.
Unfortunately, because of the slow disks, the backups were taking ~6-8 hours every night which
was longer than the desired backup window.
Because of the slow backups, ACME decided to switch to incremental backups. This provided a
significant boost in performance, shrinking the backup windows to 2-3 hours each night. However,
they now need to run occasional full backup. Keeping 30 days of retention with a full backup once
a week requires far more space, since each weekly backup is 2.5TB.
To keep 30 days of retention requires 5 weeks of full backups, which is 12.5TB, plus 25 days of
incremental backups, at 100GB/day required more than 15TB of disk space.
ACMEs administrators considered the possibility of running full backups only monthly, but this still
meant that, to keep 30 days of retention, they would need enough space for at least 3 full backups,
and up to 58 days of incrementals, since the oldest full could not be deleted until there was a new
backup chain of at least 30 days. This would require more than 13TB of space.
Its likely that ACME Corp would have been better served to spend a little extra money on a higher
performance storage system with 8 TBs of faster disk than on a low end NAS. With the higher
performance 8TB array they would have benefited from better backup performance, faster
restores, and improved performance of Backup & Replications advanced capabilities such as
Instant Restore and SureBackup.
Estimating Repository Capacity

When estimating the amount of disk space required you must first know the following:
Total size of VMs being backed up
Frequency of backups
Retention period for backups
REV 1
Will jobs use forward or reverse incremental
You must also make assumptions on compression and deduplication ratios, change rates, and
other factors. The following figures are typical for most sites; however, it is important to
understand your environment if there are exceptions:
Compression and deduplication savings 2:1 or more; typical is 3:1 or better, but always be
conservative when estimating required space.
Typical change rate of 5% day; this can vary tremendously per server and some
environments are much higher.
Include additional space for one-off full backups, and so on.
Using the numbers above, you can estimate required disk space for any job. Besides, you should
always give plenty of extra headroom for future growth, additional full backups, moving VMs, and
so on.
Deduplicating Storage Compatibility

If you plan to use a deduplicating storage appliance as a repository, consider the following options
(available on Repository page of the repository wizard):
Important
For storage systems using fixed block size, you may want to enable the Align backup file
data blocks option then Veeam Backup & Replication will align VM data saved to a
backup file to a 4Kb block boundary. This option provides better deduplication across
backup files but it can result in greater amount of unused space on the storage device and
a higher level of fragmentation.
It is recommended to disable this option for deduplicating storage that uses variable block size.
When you enable compression for a backup job, VM data is compressed at the source side
before it is transmitted to the target. However, compressing data prior to writing it to
deduplicating storage appliance results in poor deduplication ratios, as the number of
matching blocks decreases. You can use the Decompress backup data blocks before
storing option then, if data compression is enabled for a job,
Veeam Backup & Replication will compress VM data, transmit it over LAN, uncompress
data on the target side and write raw VM data to the storage device to achieve a higher
deduplication ratio.
As for any other deployment and configuration option, this is all about finding the right
balance for your environment here between better performance and higher dedupe ratio. In
most cases, the better goal might be to focus on storing and transferring the least amount of
data, as that will give the best performance. That is why inline deduplication on and
compression off is pretty much the answer for most deduplication solutions.
Using Veeam Low (Dedupe-friendly in v6.5) compression can be also a nice performance
improvement, saving 10-20% in the total amount of data that must transfer across the wire,
while increasing the size on disk typically by less than 5% (due to slightly poorer dedupe). This
10-20% savings across the wire can really add up to some improved performance if you have
many TB of full backups to run. Dedupe appliances can only ingest a fixed amount of TBs an
hour,and this performance improvement can translate into shorter backups and faster restores
(due to less data having to be transferred across the wire during restores as well), but at the
penalty of some additional loss of storage dedupe.
Examples
The examples below explain the impact of backup method and retention policy on the estimated
repository size, assuming environment is the same in all three cases.
REV 1
Environment: 10 VMs, 100GB each, 80GB avg/used

2:1 Estimated Compression/Deduplication, 5% daily change
Example 1
Backup: Reverse Incremental, Daily Backup, 30 Day Retention
Estimated Full Backup Size:

10 * 80GB (Used space) * 50% (2:1 Compression) = 400GB
Estimated Reverse Incremental Size:

10 * 80GB * 50% (2:1 Comp) * 5% (Change Rate) * 29 (reverse incremental restore
points) = 580GB
Estimated total Backup Size:

400GB + 580GB = 980GB
Example 2
Backup: Forward Incremental, Daily Backup, 30 Day Retention, Weekly Full

Estimated space for 6 Weekly Fulls (Max required for 30 Day Retention):
400GB * 6 = 2400GB
Estimated Forward Incremental Size Max:

10 * 80GB * 50% * 5% * 32 = 640GB

2400GB + 640GB = 3,040GB (~3TB)
Example 3
Backup: Forward Incremental, Daily Backup, 30 Day Retention, Monthly Full

Estimated space for 3 Monthly Fulls (Max req for 30 Day Retention):
400GB * 3 = 1200GB
Estimated Forward Incremental Size Max:

10 * 80GB * 50% * 5% * 60 = 1200GB

1200GB + 1200GB = 2,400GB (~2.4TB)
To summarize, when estimating the size of your repositories, use the following best practices:
Be conservative when estimating compression and deduplication ratios if actual ratios

and disk content are unknown.
Use higher estimates for change rate if a significant number of servers are transactional
such as SQL and Exchange
Include enough free space to take at least one extra full backup for each job
Sizing Veeam Backup & Replication Server

The Veeam Backup and Replication server handles all communications with vCenter/ESX(i) hosts. It
coordinates job schedules, provides the management interface, schedule jobs, collects statistics
and otherwise manages the operations of the backup environment.
This server stores its configuration and job history in a Microsoft SQL database. The Veeam Backup
and Replication setup will install SQL 2008 R2 Express SP1 (for v6.5) or SQL 2005 Express SP4 (for
v6.0 and v6.1); it is also possible to use a standalone SQL server. The SQL Express server instance is
sufficient for most environments, and the decision to use a dedicated instance is not typically
based on capacity, but rather on operational and/or administrative reasons.
REV 1
Tip
If the environment already has a robust, highly available SQL infrastructure, then a standalone SQL
server may be an excellent option. However, this introduces an extra dependency for the Veeam
Backup & Replication environment. In general, it is suggested to use the bundled SQL, but
environments with more than 1000 VMs may benefit from a dedicated SQL environment.
The Veeam Backup & Replication server starts a management process for each active job. This job
manager communicates with vCenter server and enumerates the vSphere infrastructure to
determine which objects should be backed up. Enumeration data is then cached by the job
manager agent for the duration of the job. For larger environments, this information can be of
significant size, and each process can use as much as 500MB of memory, with 200-300MB being
typical. Thus, you need to ensure that Veeam Backup & Replication server has enough memory to
run as many concurrent jobs as required in your environment.
Also, when many jobs are running, the system can spend a significant time collecting real time
statistics from the various proxies that are actually running the job. This can lead to significant CPU
usage simply tracking all of the changing data. So, as a rule of thumb, there should be at least one
vCPU/core for every 8-10 concurrent jobs with a minimum of 2 vCPUs/cores.
Planning for Data Recovery & Verification

Connection to NFS Server
To be able to successfully connect an ESX(i) host to the NFS server, you should make sure that the
ESX(i) host has a proper network interface configuration and can access the server on which
Veeam vPower NFS Service is running.
When connecting to the NFS server, the ESX(i) host uses a VMkernel interface. That is why ESX(i)
host you are using must have a VMkernel interface otherwise vPower NFS mounting on ESX(i)
host will fail.
By default, VMkernel interfaces are not available for non-ESXi versions, so you will have to add
them on the ESX host to be able to connect to the NFS server.
Tip
If the NFS server and ESX host are located in the same subnet, the ESX host should have a
VMkernel interface in the same IP-network as the NFS server.
If the NFS server and ESX host are located in different subnets and use a router for
network access, in addition to creating a new VMkernel interface, you will have to
manually specify routing settings in the IP routing table on the ESX host.
To check whether an ESX host can access the NFS server or not, you can use the vmkping utility on
the ESX host. The vmkping utility is similar to the ping tool the only difference is that ICMP
packets are sent via the VMkernel interface, not the service console interface.
Reaching Optimal Performance

When planning for data recovery and verification, you should also remember that vPower NFS was
not designed to deliver high throughput but to be your "spare tire" in case of failure and to
allow the machine to be brought online quickly, with minimal impact on end users.
The primary factors influencing vPower NFS throughput are as follows:
Disk I/O latency

Network latency between ESX host and vPower NFS proxy, as well as between vPower
NFS proxy and repository
CPU power
If you want to get the absolute maximum performance out of vPower NFS, you should backup to a
physical server with fast local disk (15K SAS work great, but some SSD are even better), and that
REV 1
machine should be both the repository and the vPower NFS server. That keeps the latency down to
the minimum possible level.
Overall, to get the best performance out of SureBackup jobs, FLR, and Instant Recovery, consider
the following:
Besides Windows-based backup repository servers, Veeam vPower NFS Service can run on
any Windows server you choose, including the Veeam Backup server itself. However, in
this case, performance may be much lower, because instead of a direct connection
between the ESX(i) host and the backup repository, the connection will be split into two
parts: ESX(i) host to NFS server and NFS server to backup repository.
If you store backups on a Windows-based repository, it is highly recommended to enable
the vPower NFS Server on this repository (so the vPower NFS Service will run on the
managing Windows server).
If your backup proxy is a VM with the HotAdd access to the source datastore, during the
full VM restore, Veeam Backup & Replication will use the Virtual Appliance transport mode
to write the VM data from the backup proxy back to the datastore. This speeds up the
restore process and reduces the load on the network.
Using high-performance storages as repositories is a recommended approach. The VM

boot-up speed will degrade on a slow storage, so make sure that the speed of your
backup repository will support your RTO.
The closer your storage is to the vPower NFS server, the faster your VMs will come up.
Local storage is best if available.
Make sure your vPower NFS server has sufficient RAM. For example, for booting more than
2 VMs it is recommended to have at least 6-8 GB of memory free if you plan to perform a
restore (which consumes memory as well).
Be careful if planning to recover from files stored on deduplicating appliances. They often
have decent write speeds, but trying to access the full disk all at once (to start a VM) can
cause severe latency. This happens due to the files that have to be undeduped and
presented to the Veeam server (to be then presented to VM).
The VMs will also consume resources on the host you are booting them up. Thus, avoid
choosing a host that is already (over)utilized otherwise, will not only the SureBackup
VMs, but also the rest of the production VMs may suffer from poor performance.
Keep in mind that the VMs are booting from the backup files themselves, so the more
points your VM goes through, the slower its boot-up is.
For instance, using a Forward incremental backup that has not had a synthetic full for a
month, or a Reversed incremental from 2 weeks ago, without an active full in between,
will require Veeam to access more files, slowing down the process.
If your organization requires faster restores of multiple critical VMs, consider replication instead.
REV 1
JOB SETUP
When starting to put it all together and configure your jobs and schedules, consider that there is
no universal way to create jobs that will satisfy the requirements for all environments. To choose
the best configuration for the particular situation, you should understand the environment and
impact that your choices will make. Below are various guidelines, advantages and considerations
for those decisions.
Object Selection
Veeam Backup and Replication provides flexible selection of objects that should be included in the
job. In the Virtual Machines step of the job wizard, the Add Objects screen offers various views
into the vCenter architecture that match the views provided by the vSphere client. This screen also
includes advanced methods of exclusion that allow you to select a parent object, but then exclude
child objects, or even individual disks within a VM. You can switch between the Hosts and
Clusters, VMs and Templates or Datastores and VMs view by pressing the appropriate button
on the backup object selection screen.
More guidelines on object selection can be found in the table below:
REV 1
Recommendation
Explanation
Create jobs with VM counts that

are reasonable for the backup
window.
When attempting to backup 100 VMs within two hours, it is

unlikely that placing all of them into a single job will
accomplish that goal because the VMs will be processed in a
serial way. Assuming they are of similar size and change rate,
splitting them into 4 jobs of 25 VMs each will provide better
throughput, but you must have the CPU and repository
performance to support this.
Create jobs that contain a

manageable amount of data.
Each job creates its own backup files. Creating a single job that
contains 20VMs, each being 500GB (10TB of total VM data) is
unlikely to be able to complete in a reasonable amount of time,
and will create files that are large and difficult to manage. Also,
performance decreases and memory requirements increase as
the size of the backup data increases.
For maximum performance and reliability, it is recommended
to meet the following guidelines for total size of VM data
within a job:
Local Target (1MB blocks): 8TB
LAN Target (512KB blocks): 4TB
WAN Target (256KB blocks): 2TB
Note: These are ideal maximum values and it is suggested to
keep jobs smaller to allow for data growth.
For individual VMs with large amounts storage (>2TB) it is
generally recommended to include only a single VM in the job.
Group similar VMs in the same

job, especially those created from
the same or similar templates.
VMs created from the same or similar templates will increase

dedupe, but keep in mind backup windows and size of the job
for manageability.
Select objects based on resource

pools, virtual infrastructure
folders, or datastores. For
example, if you need to perform
backup of VMs residing on one
datastore, instead of creating
several backup jobs working with
this datastore, you can create a
single backup job and add the
datastore as a VM container to it.
Creating jobs based on resource pools, folders, or datastores

can simplify management of backups. New machines that
become members of these groups are automatically included
in the backup job.
Notes:
This approach requires monitoring of jobs to make sure
there is enough space.
If using datastores (or a mix of resource pools), make sure
you do not get overlap in object selection, since VMs have
disks in multiple datastores.
Limit the number of exclusions

used in backup object selection.
While exclusions can be very useful, virtual infrastructure has a

tendency to be dynamic and changes over time, and you must
carefully consider their use in your environment. Its quite easy
for a VM to be moved to a folder or resource pool that is
excluded and move jobs, or become unprotected.
Setting De-duplication and Compression Level

In almost all cases de-duplication should be left enabled.
Veeam uses source side de-duplication which will decrease the amount of data that must be
transferred to the target repository. This is true even when used with hardware de-duplication
appliances as well as during replication which will reduce the amount of data being replicated.
When choosing the target mode, you should generally follow the guidelines as described in the
De-duplication and Compression sections above.
For very high change rate VMs such as Exchange and SQL servers, there can be significant
advantages to choosing WAN target mode (256K block size) even for local backups. However,
there is a cost to pay in CPU overhead when choosing WAN target mode. Testing in the field has
REV 1
shown a reduction of 50% or more in the size of incremental data when using WAN target mode
for incremental backups of highly transactional servers.
For compression, the Optimal level is almost always the best, but if the target is a hardware
deduplication appliance, you will generally achieve the best compression and deduplication ratios
by writing the data to the storage uncompressed, or by using Low (Dedupe-friendly)
compression level. Since the repository has the option to un-compress the data prior to writing it
to the target, this option is the recommended one for such cases.
There is also an option to align the data on 4K blocks, which can be helpful for dedupe storage that
uses fixed block sizes.
Choosing Backup Method

The best backup method will vary per-job and per-repository. The following are some general
recommendations to use as guidelines for setting up your backup jobs:
Recommendation
Considerations
Reverse incremental mode generally

provides the best balance of performance
and space savings.
Since each changed block requires 3 I/Os (1x read, 2x write), the
performance of the target storage has a significant impact on
the performance of this mode. This can be especially noticeable
for VMs with a high random change rate, or when running
multiple simultaneous jobs, and is more noticeable on low-end
storage or de-deuplication appliances.
Forward incremental with synthetic full

provides the fastest backups with the
least production impact.
Consider the cost of moderate target storage I/O: the synthetic

full process requires 3 I/Os for every block (2x read, 1x write), so
processing a week of incremental backups can take hours or
even days, based on the amount of data and performance of the
target storage.
This method requires much more storage than reverse
incremental, especially for long term retention but this is
significantly offset when using hardware based deduplication
(although many hardware deduplication appliance perform
poorly for synthetic fulls).
Forward incremental with synthetic full

with transform provides the fastest
backups with the least production impact.
Consider the cost of heavy target storage I/O: the synthetic

full with transform process requires 4 I/Os for every block (2x
read, 2x write). This can really stress target storage if run once a
week.
Forward incremental with active full

provides fast incremental backups,
requiring the least I/O load from the
target storage.
Requires an occasional active full backup, impacting the

source storage. This method is generally considered the best
for dedupe targets; however, it requires more storage if
compared to reverse incremental.
Environments making extensive use of

virtual labs should generally use forward
incremental.
While a virtual lab is active, the backup file is locked this

means that reverse incremental backups cannot be run.
Veeam will automatically tear down the virtual lab environment
to perform a backup, and this can cause issues if you are utilizing
the virtual lab extensively.
This limitation does not apply to forward incremental backups,
though.
Load Balancing
Veeam Backup & Replication utilizes a serial approach to backing up VMs within each job. This
means that only one VM will be backed up at a time during the duration of the job. When running
multiple jobs, attempt to spread the load across source and target disks. Having too many jobs
accessing the same disks will place significant load on the source or target storage and make the
REV 1
job run slower or potentially have a negative impact on the VMs performance. To help mitigate
this problem, utilize the throttling capabilities of the proxies and repositories.
Veeam also utilizes award-winning load balancing that allows you to balance your jobs across your
infrastructure utilizing whichever proxies are available.
For more details on load balancing, please refer to the User Guide.
REV 1
PLANNING FOR DR: CONFIGURATION

BACKUP
Starting with Veeam Backup & Replication version 6.5, you can create a configuration backup of
the Veeam Backup server. During configuration backup, the configuration data is exported from
the Veeam Backup & Replication SQL database and saved into a backup file on the repository. If the
Veeam Backup server fails for some reason, you can re-install it and then quickly restore its
configuration from the backup file.
Alternatively, you can apply the configuration of one Veeam Backup server to any other Veeam
Backup server in your backup infrastructure this may be helpful, for example, if you need to
migrate your current Veeam backup server to a new one. For that, just create configuration backup
of existing Veeam backup server, then install a new backup server from scratch, and import
configuration.
Periodic configuration backups reduce the possibility of data loss and minimize the administrative
overheard if any problem with Veeam Backup server(s) occurs. So, it is recommended that you
schedule configuration backup job to be run periodically and to store configuration backups on
the backup repository other than the default one. In this case, configuration data of the Veeam
Backup server(s) will be available for recovery even if the Veeam Backup server fails.
Before you restore Veeam Backup & Replication configuration, do the following:
1.
2.
3.
Make sure that the repository with a configuration backup (.bco) you plan to use for
restore is added to the Veeam Backup & Replication console.
Stop all jobs that are currently running. During configuration data restore, Veeam Backup
& Replication temporary stops all Veeam Backup & Replication services and jobs.
Check the version of the Veeam Backup server. You can restore the backup configuration
on the server of the same version.
To learn more about configuration backup and restore functionality, please refer to the User Guide
and Performing Configuration Backup and Restore - Veeam Backup & Replication for VMware, Help
Center section.
REV 1

Veeam Backup and Replication Best Practices Deploy and Configure VMWare

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Veeam Backup and Replication Best Practices Deploy and Configure VMWare

Uploaded by

Copyright:

Available Formats

Veeam Backup & Replication

2013 Veeam Software.

VCENTER SERVER ................................................................................................................................... 35

CONTACTING VEEAM SOFTWARE

ABOUT THIS DOCUMENT

Architecture and main components overview

vSphere virtual environment considerations

Job setup and scheduling

Scalability and sizing

Document Revision History

Minor text edits and graphics update.

Veeam Backup Server

CIFS (SMB) Share

Veeam Backup Search

At present, the search functionality is supported for Windows-based VMs only.

Veeam Explorer for Exchange

Exporting mailbox folders and items as Personal Folder Files (.pst)

INFRASTRUCTURE AND PROCESSES

Backup to SMB Share

Backup to Windows or Linux-based Repository

Backup to SMB Share

A source backup proxy in the production site

Replication bandwidth estimation has always been a challenge, depending on multiple

Recovery & Verification

Recovery Verification (SureBackup)

The restore process is always performed via the network.

The archived image of a VM remains in a read-only state to avoid unexpected modifications.

UNDERSTANDING VEEAM BACKUP &

Number of VMs to be protected

Preferred object grouping (by OS, by application, and so on)

Amount of data to protected

Amount of changed data per VM

Frequency of protection (RPO)

Number of restore points

Archive requirements (Tape/Offsite)

Performance impact on environment (backup/replication window)

Veeam host resources available

Target storage capacity

Target storage performance

Target storage capabilities (hardware compression/deduplication)

Available bandwidth (for offsite backup or replication)

How It Works: Backup Methods

Uses absolute least amount of space

Requires significantly more I/O on target storage (1x

Backup files are not changed after they are

Easier for GFS style staged retention policies -just

Works well with dedupe storage - required full

Backups can continue even when earlier backup

Synthetic Full takes significant

Active Full a periodic full backup

How It Works: Transport Modes

The backup proxy sends the data to target.

How It Works: Retention Policies

Indexing and Search

To coordinate proper indexing activities, Veeam Backup & Replication deploys an

Small-size Environment or Pilot: Simple

It is used as the default backup repository.

Example 1: All-in-one Physical

This scenario may be appropriate for development clusters or smaller special-purpose

Medium-size or Large-scale Environment:

Example 2: Backup with multiple virtual proxies

A job can be explicitly mapped to a specific proxy.

Another advantage of the advanced deployment scenario is that it contributes to high