Guide Veeam Backup Microsoft Office 365 v4

Veeam Backup
for Microsoft Office 365

Technical deployment and configuration guide
version 4.0
Michele Domanico
Contents
Introduction ...................................................................................................................................................................... 4
Overview of Veeam Backup for M icrosoft Office 365 ................................................................................................... 4
On-premises deployment .................................................................................................................................................. 5
Public cloud deployments .................................................................................................................................................. 5
Service providers for single-tenants (exclusive mode) ......................................................................................................... 6
Service providers for multi-tenants (shared mode) .............................................................................................................. 6
General deployment principles....................................................................................................................................... 6
Infrastructure components ................................................................................................................................................ 7
Prerequisites .................................................................................................................................................................. 10
General infrastructure recommendations .......................................................................................................................... 11
Deployment models ...................................................................................................................................................... 12
Architecture for on-premises deployment ......................................................................................................................... 14
Architecture for Microsoft Azure Cloud ............................................................................................................................. 14
Architecture for public cloud ............................................................................................................................................ 17
Architecture for service providers (exclusive mode)........................................................................................................... 19
Architecture for service providers (shared mode) .............................................................................................................. 20
Web portal integration .................................................................................................................................................... 22
Configuration maximums................................................................................................................................................. 23
Veeam Backup for M icrosoft Office 365 infrastructure planning.............................................................................. 24
VBO server ..................................................................................................................................................................... 27
VBO proxy ...................................................................................................................................................................... 28
VBO repository ............................................................................................................................................................... 30
Storage provisioning for Microsoft Office 365 backup data ...................................................................................... 30
Supported data retention types ....................................................................................................................................... 31
Microsoft Exchange backup ............................................................................................................................................. 33
Microsoft SharePoint and OneDrive backup ...................................................................................................................... 34
Considerations about Blob Storage................................................................................................................................... 36
Operational guidelines for backup and restore jobs ................................................................................................... 38
Backup job considerations ............................................................................................................................................... 39
Restore job considerations .............................................................................................................................................. 42
Office 365 throttling policy .............................................................................................................................................. 43
Veeam Backup for M icrosoft Office 365 protection .................................................................................................... 45
Summary ........................................................................................................................................................................ 47
About Veeam Software ................................................................................................................................................. 48
© 2019 Veeam Software. Confidential information. All rights reserved. All trademarks are the property of their respective owners. 12.19.2019 | 1
Abbreviations table
(A) DNS host address record
AMI Amazon Machine Image
API Application Programming Interface
AWS Amazon Web Services
BaaS Backup-as-a-Service
Blob Binary Large Object file
BYOL Bring-your-own-license
CA Certification authority
Cmdlet PowerShell command let
CIFS Common internet file system
CPU Central processor unit
DAS Direct attached storage
DNS Domain name server
DRaaS Disaster Recovery as a Service
EC2 Elastic compute cloud
EBS Elastic block storage
eSATA External serial advanced technology attachment
FQDN Fully qualified domain name
HBA Host bus adapter
Ipv4 Internet protocol version 4
Ipv6 Internet protocol version 6
iSCSI Internet small computer systems interface
JET Database Microsoft JET blue database
MSG Microsoft Outlook message file
pRDM Physical raw device mapping
PST Microsoft Outlook personal storage table
PTR DNS host address pointer record
RDM Raw device mapping
RPO Restore point objective
RTO Restore time objective
S3 Simple Storage Service (Amazon)
SAN Storage area network
SMB Server message block
SSL Secure socket layer
USB Universal serial bus
VBO VBO Backup for Microsoft Office 365
VBO Proxy VBO Backup for Microsoft Office 365 proxy
VBO Repository VBO Backup for Microsoft Office 365 repository
VBO Server VBO Backup for Microsoft Office 365 server
VCC Veeam Cloud Connect
VCSP Veeam Cloud & Service Provider
VBR Veeam Backup & Replication™
VM Virtual machine
vRDM Virtual raw device mapping
Why Use Veeam for Office 365 Backup
As of today, Microsoft Office 365 is the largest solution for digital collaboration. It provides a global infrastructure
and is responsible for the uptime of Office 365 cloud services. The Microsoft data center’s responsibility covers the extended
geo-replication of the data and it adheres to the latest security and regulatory requirements. However, Office 365 customers
are still responsible for the access and control of their data that resides in Office 365 data centers.
Furthermore, customers with Office 365 tenants can choose to connect to their on-premises workloads and benefit
from a seamless user experience, even when moving between different environments (i.e., online and on-premises)
and using a hybrid platform. Office 365 has a high adoption rate by businesses of all sizes.
While Office 365 offers undisputed flexibility with the integration of new and existing solutions, it only focuses on infrastructure
management and uptime rather than hosted data and long-term protection of that data. The responsibility for data protection
and its availability still rests on the respective data owners who adopt Office 365 cloud services.
Office 365 data centers provide replication technologies to make Office 365 data available in different locations within
the infrastructure. The customers, as owners of the data, still have to provide complete access and control of their data.
Infrastructure uptime does not cover cases in which the data center itself can provide an effective way to recover from:
• Accidental deletions
• Data loss or corruption
• Rogue applications and insider threats
• Outages
This white paper covers the implementation of Veeam® Backup for Microsoft Office 365 and its architecture.
It also provides best practices for both short- and long-term protection along with recommendations for several deployment
types for on-premises, private cloud, public cloud and service provider scenarios.
Overview of Veeam Backup for Microsoft Office 365
Veeam Backup for Microsoft Office 365 (VBO) is a scalable solution that offers protection and availability for Office 365 data.
The solution covers on-premises, private cloud and public cloud deployments with flexible options. All deployment scenarios
are covered in this document. The following table shows the supported and available deployment scenarios
Deployment options VBO
On-premises ✔
Public cloud ✔
Service provider for single-tenant (exclusive mode) ✔
Service provider for multi-tenant (shared mode) ✔
On-premises deployment
For customers who want to have a terrestrial backup copy of Office 365 data, an on-premises deployment is the best option because
it has the ability to scale-out from simple to advanced installations, as mentioned later in this document. This kind of deployment
provides the flexibility required by an organization that uses Office 365 hybrid deployments where the protected data resides
within any combination of online and on-premises Microsoft Exchange, SharePoint and OneDrive for Business infrastructures.
The “Infrastructure components” and “Architecture on-premises” sections of this document provide more details about this
deployment type. It uses a subscription license that is based on the number of Office 365 users who need to be protected.
Public cloud deployments

For customers who have an existing footprint in the public cloud or for those who want to host the infrastructure in a separate data
center, a VBO deployment can operate from any public cloud and provide a complete cloud-agnostic approach. For this purpose,
this document covers the most popular public clouds adopted by businesses of all types: Microsoft Azure and Amazon AWS.
In the case of Microsoft Azure, there is a certified, pre-installed application available in the Azure Marketplace with VBO.
Azure Marketplace requires the customer to enter the details of the Office 365 tenants. In general, data can be directly stored
into Azure Managed Disks. As of VBO v4, Blob Storage can also be achieved through “Extended Backup Repositories” which
uses Microsoft Azure storage offerings. The section “Considerations about Blob Storage” covers this topic in more detail.
This deployment type follows similar architecture considerations to the on-premises model. In this scenario, all the VBO
components are hosted in Azure as covered in the “Architecture for Azure deployments” section of this document. It uses
a bring-your-own-license (BYOL) model that Office 365 users need to protect. Veeam will not charge additional fees for ingress
or egress data, but additional fees include Azure infrastructure costs. Typically, ingress costs are free. Egress costs are charged
only once they go over 5 GB. Costs are billed monthly.
In the case of Amazon AWS and other public clouds, it’s possible to install a VBO server that follows Veeam system
requirements. By default, all backup data will be automatically saved on repositories to local disks that are attached to the VBO
virtual machine (VM). As of the release of VBO v4, Blob Storage can be achieved with “Extended Backup Repositories” by using
Amazon S3. The section “Considerations about Blob Storage” covers this topic in more detail.
This deployment type follows similar architecture considerations to the on-premises model. In this scenario, all VBO components
are hosted in the public cloud infrastructure of choice, as detailed in the “Architecture for public cloud deployments” section
of this document. It also uses a BYOL model that Office 365 users need to protect. Veeam will not charge additional fees
for ingress or egress data. Other fees might still be operated by the public cloud provider of choice and this does not include
public cloud infrastructure costs.
Service providers for single-tenants (exclusive mode)
Veeam Cloud & Service Providers (VCSP) may offer the option to access a dedicated VBO infrastructure that’s exclusive to their
single tenant. In this configuration, the single tenant allows the service provider to access, back up and restore content on their
behalf. In this configuration, the customer typically uses the service provider infrastructure to protect their Office 365 data
and the assigned storage from the service provider as a repository for their own data. The customer might also have full access
on the VBO server application and from there, all operations can be controlled depending on the service provider offering.
If the customer has a hybrid configuration of Microsoft Exchange and SharePoint to protect, it’s required that the customer
provides the fully qualified domain names (FQDN) of the respective on-premises Exchange and SharePoint servers to the
service provider and to allow connectivity to these servers from the service provider side. To a certain degree, the service
provider for single-tenant and on-premises deployments are very similar. The main difference from an architecture point
of view is that the customer wants to have the VBO architecture in their own infrastructure or to use service provider data
center resources. The “Architecture for service providers (exclusive mode)” section of this document provides more details
on this deployment type. The license model is operated by the service provider and is typically based on the number of Office
365 users that need to be protected and the cost of storage, which might be included into the same billing.
Service providers for multi-tenants (shared mode)

VCSPs can host and integrate the VBO server deployments with existing Veeam Cloud Connect infrastructure. In this scenario,
a VCSP can use a single VBO deployment in multi-tenant mode. In this mode, all backup data and repositories are separated
and the customers can use Veeam Cloud Connect gateways to securely access and recover content. In this case, the customer
has no control over VBO server installations on the service provider side. Customers can use Veeam Explorer™ for Microsoft
Exchange, SharePoint and OneDrive for Business in their on-premises environment to restore data from backups stored
in service provider storage. With this configuration, the service provider has visibility into all configured Office 365 tenants
and single tenants have no visibility to other tenant instances that share the same platform. Tenants can only access their
own data from the backup jobs that the service provider has created for them.
With this type of deployment, service providers use the multi-tenant capabilities of VBO. This includes the ability to designate
specific resources (i.e., a VBO proxy and repository) to selected customers based on contract and service levels.
With this deployment type, service providers can offer:
• Full isolation on the tenant level

• Full isolation on the VBO proxy to use for backup and restore jobs
• Full isolation on the VBO repository where Office 365 data can be stored
More deployment details are covered in the “Architecture for Service Providers (shared mode)” section of this document.
For this deployment type, the license model is operated by the service provider and is typically based on the number
of Office 365 users that need to be protected and the cost of storage, which may be included in the same billing.
General deployment principles
VBO can run in on-premises, private cloud and public cloud environments. The prerequisites and how these components work
for each environment is very similar. IT organizations have the flexibility to choose from different designs based on their current
requirements. Typically, the VBO server is installed on-premises where the storage for backup data is also located. In some
instances, it might be required to run and store backup data into a completely different infrastructure for full disaster recovery
(DR) purposes. This can be either a public cloud provider or a VCSP. All of these options are covered in the “Deployment models”
section of this document.
These are common principles to all deployment types:
• All deployment types share the same technology and ability to scale. VBO does not require customers to install agents
to retrieve or restore data.
• Backup and restore operations use the latest Microsoft APIs (like Microsoft Graph) for different platforms including
Microsoft Exchange, SharePoint and OneDrive for Business.
• VBO also interacts with legacy Exchange Web Services (EWS) along with various Microsoft APIs and PowerShell commands
to directly connect to Office 365 hybrid deployments. For this reason, the VBO server or one of its backup proxies require
direct access to the internet or at least to Office 365 servers in the Microsoft Azure cloud.
• The VBO server and proxy also support connections through an internet web proxy. Also, in advanced deployments where
multiple proxies are available, it’s possible to use different web proxy configurations. Service providers can use this setting
to further harden security and segregate communications for multi-tenant environments.
• Internet connectivity is required when operating with a third-party trusted certificate authority (CA).
• Full support for separate service accounts with Microsoft Exchange, SharePoint and OneDrive.
• Full support for multiple backup accounts with SharePoint Online and OneDrive for Business, which helps
to reduce Office 365 throttling.
• Full support for non-administrative service accounts if the necessary Office 365 roles and permissions are granted.
Infrastructure components
The VBO architecture consists of four main components:
1. VBO server
The VBO server can be installed on a physical or virtual machine. Supported operating systems are Windows 7 SP1, Windows
8.x, Windows 10, Windows 2008 R2 SP1 and later. Only 64-bit versions are supported. The VBO server is the main component
and is responsible for the creation of jobs, configurations and notifications. One VBO server can protect multiple Office 365
organizations including a combination of on-premises, online and hybrid instances within just one installation.
With advanced deployments, the VBO server can communicate with multiple VBO proxies and repositories
to address scalability requirements.
The VBO server includes the following main components:
• Shell UI: Responsible for providing graphical access to all VBO functionalities.
• Rest API: Provides access to RESTful API, which allows integration with third-party applications.
• PowerShell: Enables the orchestration and automation of VBO server deployments and pertinent backup and restore jobs.
2. VBO proxy
While the VBO server handles configuration and management functions, the VBO proxy needs to execute
both backup and restore jobs. The role of the VBO proxy is built in the VBO server along with the main VBO service
(veeam.archiver.service). For larger deployments, the VBO server can delegate backup and restore operations to additional
proxies (veeam.archiver.proxy). Data is then retrieved from the Office 365 organization and on-premises instances and saved
onto the VBO repository. When performing restores, the VBO proxy reads data from the VBO repository and writes directly
to the pertinent instance which will either be online or on-premises. It also applies to scenarios where tenants’ organizations
are part of a hybrid deployment or simply are standalone instances.
3. VBO repository
The backup repository is the location where Office 365 data is stored. It uses a database format (JET DB) that is directly
mounted to the VBO proxy. Backup repositories are supported on the following types of storage:
• Directly attached storage (DAS): Includes DAS, USB/external serial advanced technology attachments(eSATA)
and raw device mapping (RDM).
• SAN: The VBO server and proxy can be connected to the storage area network (SAN) fabric via hardware, a virtual host
bus adapter (HBA) or software internet small computer system (iSCSI) initiators. This provides direct access to the VBO
repository. For simple deployments, the SAN is presented to the VBO server. With advanced deployments, SAN storage
is presented to the VBO proxy directly. The latter proves useful when delegating the execution of jobs to VBO proxies
for larger environments.
• SMB (Server Message Block 3.0)
• Experimental: Since the VBO server and the VBO proxy run under a local system account, the VBO server’s computer
account must have the corresponding permissions on the network share. Windows 7 SP1 and Windows 2008 R2 SP1
do not support SMB (3.0) shares.
• Blob storage (Microsoft Azure Blob, AWS S3, IBM cloud, any S3 compatible)
4. Veeam Explorers for M icrosoft Ex change, ShareP oint and OneDrive for Business
Veeam Explorers for Microsoft Exchange, Microsoft SharePoint and OneDrive for Business assist the VBO architecture
with the following tasks and use cases:
a) In-place and out-of-place restores:
By default, these restores provide the capability to recover data to the original location. This is known as an in-place restore.
Where required, the ability to perform restores to a different location is also supported. In this case, it performs
an out-of-place restore.
Veeam Explorers recover data between online, on-premises and hybrid Office 365 deployments. It does not require a staging
server during restores since data is read directly from the backup in the VBO repository. With this same mechanism,
Veeam Explorers also support the export of several items in different formats, such as:
• Attachments and Microsoft Outlook *.pst and *.msg files

• SharePoint sites to the original location with permissions and versions
• SharePoint list, libraries, folders and files back to its original format or a zip-compressed version
• OneDrive for Business files and folders to the same or new locations as individual files or zip-compressed ones
To export Exchange content in these additional formats, the server where the Veeam Explorer component is installed requires
a local installation of Outlook x64 edition. With simple deployments, the Veeam Explorers can be installed by default on the
VBO server. For large or advanced deployments, it’s possible to install additional roles on other servers. This provides the ability
to choose the best resource to reduce the recovery time objectives (RTO).
Other use cases include browsing, searching and exporting content.
b) Browse content
Once Office 365 organization data (both online and on-premises) is stored in a VBO repository, the Veeam Explorer component
directly reads these backup files to present the entire content in a hierarchical format that shows:
Exchange backup
• Organization name (i.e., backup job name and a selected point in time)
• Mailboxes (applies to shared, public and resource mailboxes and includes a legal hold)
• Folders (includes hidden, deleted and in-place holds)
• Items (includes all mail item types, deletions and in-place holds)
SharePoint backup
• Organization name
• SharePoint site collections (includes sites, sub-sites and personal site structures)
• Document libraries and lists
• Documents and items
OneDrive for Business backup
• Organization name
• OneDrive for Business users with a folder structure
• Items
For each object, built-in browsers offer a context-sensitive option to send, restore and export.
c) Search for content
The Veeam Explorer components include an “advanced find” capability to perform sophisticated eDiscovery searches by using
different criteria based on address, date, time, mail, post, appointment, task, journal and notes for Exchange. Calendar,
contact, document, message and task fields that apply to both SharePoint and OneDrive for Business.
All searches are performed against the data in the VBO repository. For this reason, placing this component close to the VBO
repository ensures quick searches even against large sets of data. This is the recommended option when searching the content
against multiple mailboxes, multiple SharePoint and OneDrive datastores and even across multiple organizations.
d) Export content
Veeam Explorers can select content to export by running searches based on custom criteria and then estimate the size
of the content.
This option is useful especially during Exchange migration scenarios as it allows users to:
• Select content based on criteria that should be exported into the new location, either on-premises or online (Exchange only)
• Help with staged exports from an on-premises deployment to Office 365
• Export data within Office 365 and hybrid deployments
Prerequisites
There are several prerequisites to fulfill before proceeding with the installation. It is advised that users review the following
items to ensure a successful VBO implementation.
DNS name resolution

Domain name system (DNS) resolution is an essential service that the VBO components use when communicating with each
other. With advanced deployments where the VBO server communicates with VBO proxies, it is important that both forward
and reverse name resolution works as expected. For this reason, it’s recommended to:
• Provide a static IP address to the VBO server

• Provide a static IP address to the VBO proxies
• Create DNS host address records (A) and DNS host address pointer records (PTR) in DNS
• Check that IPv4 is preferred over IPv6
• Verify the fully qualified domain name (FQDN) name resolution on both sides (i.e., forward/reverse) using nslookup
or an equivalent. The query should return the IPv4 address first.
Additional proxy deployment

With additional VBO proxies, it’s recommended to use the same operating system version as the VBO server installation
or higher. The VBO proxies installed on earlier Windows OS versions than the VBO server might not provide the best
experience. This is due to the compatibility between the latest versions of Windows OS and their native JET databases.
The latest Windows OS versions are also backward compatible, but rarely the other way around. Most importantly,
both VBO servers and VBO proxies need to be part of the same or trusted domain.
Microsoft Windows Domain membership

All in one installations, as simple deployments, can be part of a Microsoft “Windows Workgroup”. For advanced deployments
where the VBO infrastructure scales out to multiple proxies and repositories, it is recommended to either join the production
Microsoft Windows Domain or place the components in a separate one hardening the security levels.
Anti-virus and HIPS

If an anti-virus or host intrusion prevention system (HIPS) is installed on a VBO server and proxy, it’s recommended that users
exclude the following locations in this table:
Path VBO server VBO proxy
%ProgramFiles%/Veeam/Backup365 ✔
%ProgramData%/Veeam/Backup365 ✔ ✔
%WinDir%/Veeam/Backup365 ✔
General infrastructure recommendations
Depending on the VBO role, there are separate default locations in which the installer runs the binaries and configuration files.
From a deployment perspective, it’s important to understand these locations. With advanced deployments, the same
components can be shared by multiple tenants. This is also very important for service providers in working with multiple tenants
(i.e., shared mode).
The table below represents the standard locations where installation and data files are located. The installation folder
includes all the binaries and main configuration files, whereas the data folder includes infrastructure configurations and other
details in the format of database files. Updates to the VBO infrastructure and job configurations are periodically pushed from
the VBO server and propagated to the VBO proxies. These proxies can work autonomously for up to 48 hours should
the main VBO server be unavailable.
VBO server VBO proxy server
Installation folder %ProgramFiles%\Veeam\Backup365 %WinDir%\Veeam\Backup365\Proxy
Data folder %ProgramData%\Veeam\Backup365 %ProgramData%\Veeam\Backup365
Backup data Not recommended Any supported storage
For all deployment types, the following should be observed:
• Backup jobs will generally consume more resources (i.e., RAM memory and disk space). The VBO repository files should
be placed on a volume with no deduplication or compression enabled. The “Storage provisioning” section provides a formula
to estimate sizing for backup data allocation.
• During restore operations, the backup data is mounted temporarily in read-only mode. No caching occurs on disk.
• Veeam Explorer for Microsoft Exchange eDiscovery searches can use large amounts of memory to search across multiple mail
stores. A way to improve this is to disable the .pst size estimation.
• By adding VBO proxies, it’s possible to delegate backup and restore operations to dedicated servers, which frees up resources
for the VBO server.
• Both NTFS and ReFS file systems are supported. When using ReFS, data integrity features should be disabled for volumes
where data folders are located or at least exclude VBO repository files. NTFS is recommended.
• In-flight encryption is built in with all backup and restore jobs.
• At-rest encryption is supported for Blob Storage repositories on Azure, Amazon S3, IBM Cloud and S3 compatible.
• Data deduplication appliances are not supported.
• Blob Storage can be used as a primary target for backups. More info on how to use Blob Storage as a primary and secondary
tier is available in a dedicated section.
• To enable the export function to a *.pst or *msg file, the Microsoft Outlook client (64-bit only) needs to be installed
onto the same VBO server where Veeam Explorer for Microsoft Exchange is running.
• No memory-intensive software should be deployed on any VBO server or proxy as it could affect the running
of the backup processes.
Deployment models
VBO can use both simple and advanced deployment models.
Simple deployment includes the installation of all components onto a single server. This machine can be either virtual
or physical. Specs should follow configuration maximums. In this scenario, all the major components (i.e., the VBO server,
proxy and repository) are installed on the same machine. A simple deployment scales out by adding multiple VBO repositories
that are operated by the same VBO server. Simple deployments are suitable for small-to-medium sized businesses (SMBs) that
want to have a terrestrial backup copy of their Office 365 data on-premises. This applies to public cloud deployments as well.
In this case, backup data is stored on repositories that are attached to the VBO servers themselves.
Advanced deployment gives the option to scale-out installations by adding VBO proxy and repository components to meet demanding
business requirements. The process of adding these components is handled by the main VBO server. When scaling out to an advanced
deployment, the VBO server installs the necessary components onto the required servers. It works by deploying the main veeam.archiver.proxy
service along with a copy of the infrastructure configuration. This newly added VBO proxy benefits from the view of the entire infrastructure
and provides the option to configure backup jobs by using additional VBO repository targets. This entire process is wizard-driven. Full automation
is also possible by using native VBO PowerShell commands. Typically, advanced deployments are used in the following circumstances:
• When reducing and removing workloads from a VBO server during backup and restore operations for very large Office 365
and hybrid deployments. Each VBO architecture component can be configured to address different requirements. The section
about VBO server planning includes information about the current recommended maximums and how many components
are needed for deployment based on specific requirements.
• When choosing specific VBO proxies to run backup and restore jobs. Each VBO proxy can be configured with dedicated settings
regarding the concurrent number of threads and the amount of bandwidth shared across threads and internet web proxy settings.
• When choosing specific VBO repositories in which to store Office 365 backup data. By doing this, each VBO repository
can use different storage types with separate retention policies. Several VBO repositories can be created to contain data
based on business units, object types and other criteria that’s pertinent to business requirements.
• With segmentation and isolation for traffic and data between different tenant organizations operated by the same VBO server.
This is an important feature for large enterprise and service provider scenarios. Traffic segmentation occurs at the network
level where the VBO proxy connects to separate VLANs. VLAN configuration occurs on the network infrastructure and data
segmentation occurs on the VBO repository level by using dedicated storage locations that correspond to each tenant.
Advanced deployments are suitable for large organizations where there is a need to protect a high number of Office 365 users
and their data. In fact, advanced deployments should be used wherever requirements include:
• Data segmentation on separate repositories (i.e., based on purpose, data criticality, department, location or other criteria)
• For medium (up to 4,000), large (up to 16,000) and extra-large (more than 80,000) amounts of tenant seats
• Multiple retention policies based on service level agreements (SLAs)
• Service providers in multi-tenant configurations
Advanced deployments is also the preferred option for service providers that can easily integrate VBO with existing Veeam
Cloud Connect infrastructures for a full multi-tenant environment. In this scenario, all restore operations will use Veeam Cloud
Connect gateways. The following is achieved:
• Service providers can use existing Veeam Cloud Connect gateways for restore operations.
• Customers can use Veeam Explorers for Microsoft Exchange, SharePoint and OneDrive for Business directly from their
Veeam Backup & Replication server.
• No additional components need to be installed from the customer side.
• Securely restore content over a connection encrypted with an SSL certificate.
At the same time, customers can take advantage of a resilient infrastructure hosted by the service provider that can run backup
and restore jobs without necessarily running or maintaining additional components in their own environment.
Architecture for on-premises deployment
With reference to the “Infrastructure components” section, the on-premises deployment is suitable for both simple and
advanced deployment models. On-premises deployments are best suited for customers with hybrid deployments where
Exchange, SharePoint and OneDrive services are using a combination of both on-premises and online.
No agents are required and the VBO server or proxy can connect to online and on-premises instances using pertinent APIs.
Then, data is stored to a backup repository. By default, Veeam Explorers can be installed on the VBO server itself.
For distributed environments, it’s recommended to install Veeam Explorers on separate machines. This allows the VBO server
to use available RAM memory without sharing resources with other processes. Additional Veeam Explorers cannot be installed
on machines with the VBO proxy role.
VBO requires the disk to be the primary backup target. DAS, SAN and server message blocks (SMB) 3.0 share storage types
are supported. Although DAS is the easiest one to implement, SAN and SMB can be also used for larger environments.
In the case of SAN storage, the backup repository can be provided as raw device mapping (RDM). For virtual infrastructures,
the virtual RDM (vRDM) is supported. However, physical RDMs (pRDMs) is not supported. Ideally, as a backup repository,
a SMB share should be used only if the throughput is higher than connecting the VBO server or VBO proxy to the SAN storage
through the iSCSI protocol.
All VBO components can be installed on both virtual and physical machines. However, wherever possible, VMs should
be chosen. As covered in the section “Protect VBO”, for the VBO server and its infrastructure, it’s recommended that users
choose a workload type where application, file and crash-consistent backups can be performed.
The “Considerations about Blob Storage” section provides more details on how VBO can leverage Blob Storage as both
its primary and secondary target.
Architecture for Microsoft Azure Cloud
The Microsoft Azure Marketplace provides a pre-built Azure VM with a VBO server installed on top of a Windows server VM.
Typically, this type of installation in Azure follows the simple deployment model. Default configuration mimics the same
architecture as an on-premises install. By default, the major components (i.e., VBO server, VBO proxy, VBO repository and
Veeam Explorers) are installed on the same machine.
The Azure Cloud option is suitable for customers who have an existing footprint on Azure and want a fully online deployment
of VBO. Customers who want to manage hybrid deployments need to provide the full connectivity by using a VPN route
to on-premises Exchange and SharePoint servers. No agents are required and all communications use native Microsoft APIs.
From a compute point of view, it is possible to choose between several Azure VM template instances according to requirements.
The configuration maximum section provides more details on sizing the VBO components.
From a storage point of view, it’s recommended that users create and attach Azure Managed Disks to the VBO Azure VM server
itself and use them as a local repository for Office 365 data. The “Storage provisioning” section of this document provides
more details.
From a licensing perspective, the following costs should be considered:
• VBO in Azure Cloud follows the BYOL approach and there are no additional costs from Veeam.
• No ingress or egress costs are charged by Veeam.
• There are other costs to sustain Azure Cloud deployments (i.e., VM CPUs, memory, storage, operations and egress charges
operated by Microsoft Azure).
• Backup data is stored in an Azure Managed Disk that’s attached to the VBO Azure VM.
Architecture components
According to the “Infrastructure components” section, the Azure deployment is most suitable for a simple model.
It supports adding a VBO proxy and repository where required with the advanced model.
The VBO server, proxy, repository and Veeam Explorer components are installed on the same server. While the VBO server is
responsible for providing access to the main console for job configurations and other settings, the VBO proxy connects to the
Office 365 instance using APIs to back up (i.e., download) and restore (i.e., upload) Office 365 data.
Data stored in VBO repositories is normally configured as DAS storage to the Azure VM itself (i.e., Azure Managed Disks).
This provides the best performances for read and write operations against VBO repositories. The same Azure Managed Disks
can be configured for multiple VBO repositories. Since all Office 365 data does not grow equally, it allows users to use separate
repositories based on data types (i.e., Exchange, SharePoint and OneDrive for Business).
Azure Blob Storage can be used directly as a target for the VBO repository. The section “Considerations about Blob Storage”
provides the best practices for how to leverage Blob Storage as a primary and secondary target for longer retention.
Architecture for public cloud
Amazon AWS and other public cloud providers can run a VBO server installation on a Windows server OS. Typically, the VBO
installation in public clouds follows the simple deployment model. In this case, all major components (i.e., the VBO server,
proxy, repository and Veeam Explorers) are installed on the same machine.
For public cloud providers, the VBO installation requires two steps:
a) Install the base Windows server image from an existing template
b) Install the latest VBO application
Larger environments can scale out the infrastructure by adding VBO proxies and repositories for an advanced deployment. In
this case, here’s an example with AWS:
Amazon AWS
From a compute point of view, it’s possible to choose between several AWS AMI templates to install the VBO server according
to the requirements. The “Configuration maximum” section provides more details and an idea of which VM template to select.
From a storage point of view, it’s recommended to create a volume on EBS storage and attach it to the VBO server VM itself.
This new volume can be configured to store the VBO backup repositories for Office 365 data. The “Storage provisioning” section
of this document provides more details.
From a licensing perspective, the following costs should be considered:
• VBO in the public cloud follows the BYOL approach and there are no additional costs from Veeam.
• No ingress or egress costs are charged by Veeam.
• Other costs need to be sustained with public cloud infrastructure deployment (i.e., VM CPUs, memory, storage, operations
and egress charges operated by the cloud provider).
Architecture components
According to the “Infrastructure components” section, a public cloud deployment is more suitable for a simple model. However,
it also supports adding a VBO proxy and repository with an advanced model.
The VBO server, proxy, repository and Veeam Explorer components are installed on the same server. While the VBO server is
responsible for providing access to the main console for job configuration and other settings, the VBO proxy connects to the
Office 365 instance using APIs to back up (i.e., download) and restore (i.e., upload) Office 365 data.
Backup data is stored on VBO repositories, normally configured as DAS storage to the Amazon EC2 VM itself (EBS volumes).
This provides the best performance for reading or writing operations to or from VBO repositories. The same Amazon EBS
volumes can host multiple VBO repositories. Since all Office 365 data does not grow equally, it is advised to use separate
repositories based on data types (i.e., Exchange, SharePoint and OneDrive for Business).
The “Considerations about Blob Storage” section provides more details on how VBO can use Blob Storage as both its primary
and secondary target.
Architecture for service providers (exclusive mode)
According to the “Infrastructure components” section, the service provider exclusive mode deployment is suitable for both
simple and advanced models. This type of deployment allows the service provider to address many different types of
customers. From small to large Office 365 tenants, service providers may choose to offer dedicated VBO infrastructures within
their data centers. Customers in this case can leverage a dedicated environment for their specific Office 365 tenants, typically
over a secured VPN connection and accessed through a RDP console. The customer then has full access to the VBO console to
create, run, edit and manage backup and restore jobs.
Note: Each customer only has access to their assigned VBO environment.
1 The VBO server is the main server where the tenants will connect to and manage backup and restore jobs. This model is
applicable to customers of all sizes. According to the supported configuration maximums, service providers may install additional
VBO proxies as required. The same principle applies to additional VBO repositories where different retention policies are
required.
2 The VBO proxy is the main component responsible for connecting to Office 365 tenants and backup data. This component is
also responsible for accessing the VBO repository in order to restore content to its original location in the Office 365 tenant.
3 The VBO repository is the main storage location where Office 365 backup data is stored. According to customer
requirements, the service providers may offer access to multiple VBO repositories based on different retention policies and
types of data.
4 Veeam Explorers allow users to browse, explore, restore and find specific Office 365 data directly within VBO repositories.
Architecture for service providers (shared mode)
According to the “Infrastructure components” section, the service provider shared mode deployment is suitable for the
advanced model. This type of deployment allows the service provider to address multiple customers who share the same VBO
infrastructure in multi-tenant mode. From small to large Office 365 tenants, service providers may use the existing Veeam Cloud
Connect infrastructures to:
• Provide tenant and Office 365 data segregation

• Manage backup jobs on behalf of the customer
• Allow customers to do self-service restores for their own data
The customers in this case can fully leverage a multi-tenant environment that runs entirely on service provider data centers. In
such configurations, the service provider only allows for the connectivity of Veeam Explorers. Veeam Explorers can use the
existing Veeam Cloud Connect gateway to securely browse and restore content and customers have no access to the VBO
console to create, run, edit and manage backups. Customers can only restore by leveraging Veeam Explorers for Exchange,
SharePoint and OneDrive for Business.
1 The VBO server is the main server where tenants can connect to and manage restore jobs. According to the supported
configuration maximums, service providers may install additional VBO proxies as required. The same applies to additional VBO
repositories where different retention policies are required. In this scenario, the best practice is to install the VBO server on the
same machine where Veeam Cloud Connect is running. This allows customers to use self-service restore capabilities through
Veeam Cloud Connect gateway connections. No additional components are required from the customer’s side.
2 The VBO proxy is the main component responsible for connecting to Office 365 tenants and backup data. This component
is also responsible for accessing the VBO repository in order to restore content to the original location in the Office 365 tenant.
In this scenario, a single VBO proxy can be connected to multiple VBO repositories. Based on workloads, service providers can
associate a dedicated proxy to specific backup jobs.
3 The VBO repository is the main storage location where Office 365 backup data is stored. According to customer
requirements, service providers may offer access to multiple VBO repositories based on different retention policies and types
of data. In this scenario, the service provider manages backup jobs. According to contracts offered to their customers, service
providers can choose which repositories and how many repositories to use per single customer or tenant.
4Veeam Explorers allow users to browse, explore, restore and find specific Office 365 data directly within
VBO repositories. In this scenario, existing Veeam customers can use Veeam Explorers’ shipping with the latest editions of
Veeam Backup & Replication or the latest VBO release. Veeam Backup & Replication 9.5 Update 4b and above is recommended.
In such scenario the best practice is to connect Veeam Explorers for Microsoft Exchange, SharePoint or OneDrive for Business
to the service provider Veeam Cloud Connect Gateway. This allows the Veeam Explorer from the customer side to use an
SSL encrypted connection to the VBO server installed in the service provider data center and be automatically connected
to the respective VBO repositories that hold the data. Since VBO works in a multi-tenant mode, only the pertinent backup
data is presented to the Veeam Explorer. The new option that appears in Veeam Explorers is called “Veeam Backup
for Microsoft Office 365 service provider.”
For service providers who need to provide Office 365 data backup for more than 160,000 objects, or roughly 40,000 users
in total, it is recommended that users install multiple VBO server instances. In such cases, unless there are additional Veeam Cloud
Connect servers available, VBO servers can be standalone and follow the principles of architecture for service providers (exclusive mode).
From a restore and self-restore point of view, it’s recommended that users leverage the VBO Web Portal. Large customers
and service providers can build their own portal and take advantage of the RESTful API’s shipping with VBO deployments.
Web portal integration
For service providers and large customers, the best practice is to provide access to VBO server functionalities by means
of a web portal. While a self-service restore through Veeam Explorers may be enough for the majority of requests, VBO allows
for even more flexibility by exposing all the functionalities, both inside and outside the console, through RESTful APIs and
PowerShell command-lets. Both allow for seamless orchestration and automation of all aspects of the VBO infrastructure.
For large customers and service providers who offer Backup-as-a-Service (BaaS) solutions for Office 365 data, the best practice
is to build a web portal based on built-in VBO APIs.
These allow users to:
• Create and manage tenant organizations

• Create, edit and manage backup and restore jobs
• Create, edit and manage backup proxies
• Create, edit and manage backup repositories
• Manage backup data
The VBO web portal can run on any web server and should be published to the internet. This allows any tenant to use
just a single pane of glass to manage their Office 365 backup data. Web portal connections to the VBO server are secured
with certificates. This provides the flexibility to access Office 365 backup data from any location at any time through just
a web browser.
It is recommended that the web portal option is used for:
• Service providers with customers of all sizes, particularly with small customers who need to install Veeam Explorers
for Microsoft Exchange, SharePoint or OneDrive for Business. They can simply use a web browser with a secure connection
to browse and restore their data.
• Service providers that offer a simple portal where customers are fully independent and don’t need to share any
Office 365 administrative credentials or equivalents to run backup and restore jobs.
• Service providers with tailored services that are, for example, based on backup scope, storage and retention policies.
These are available as a selection from the web portal.
• Service provider or MSP white labelling.
• Large customers who want to offload requests for single item restores from their help desk departments.
Note that these customers can still automatically create a ticket for IT service management purposes.
The VBO web portal is fully configurable. The following is a configuration example:
https://github.com/nielsengelen/vbo365-rest
Configuration maximums
This section covers the supported maximums for VBO components regarding resources like CPU and memory and backup
storage allocations like disk. Numbers may vary depending on allocated resources and workloads. The figures provided in this
section refer to any combination of online and on-premises organizations that use Microsoft Exchange, SharePoint and OneDrive
for Business. As covered in the “Infrastructure planning” section, it is a best practice to consider the number of objects rather
than the total number of users associated to different objects.
Maximum number of objects per proxy1,2 16,000
Maximum number of users per job2 4,000
Maximum number of users per proxy2 4,000
Maximum number of proxies per VBO server instance 10
Maximum number of objects per VBO server instance2 160,000
Maximum number of users per VBO server instance2 40,000
Maximum size per VBO repository3,4 Unlimited
1 Based on a VBO proxy running with 8x CPUs and 32 GB RAM memory.

2 Selecting mail, mail archive, OneDrive and sites or personal sites for each user.
3 The VBO repository consists of multiple folders that are named after the number of years of retention. For each year folder,
there is a repository file (.adb) plus a transaction and check log (.jrs and .chk). The total supported size for each .adb file is 64 TB.
For example, a three-year retention creates three folders with backup files that can grow by up to 64 TB, with one .adb per folder.
4 An automatic rule triggers when repository database files reach 59 TB. At this point, a new repository database
file is automatically created in the same storage location. This allows users to bypass the first limit.
Simple deployments
Simple deployments are suitable for smaller environments that protect up to 16,000 objects, or roughly 4,000 users, provided
that the VBO server is running with at least 8x CPUs and 32 GB RAM memory.
Advanced deployments
Advanced deployments are suitable for larger environments that protect up to 160,000 objects or roughly 40,000 users.
It is important to note that the 4,000 users per VBO proxy or up to 10 per VBO server rule is based on servers that run
with at least 8x CPUs and 32 GB RAM memory.
For service provider scenarios, it is recommended to use the advanced deployment type in shared mode with additional VBO
proxies and repositories. This reduces management costs associated with a single VBO server instance for exclusive tenants.
RAM allocation and number of repository databases per backup proxy
Default JET database instance memory consumption on VBO repository 0.1%
Default JET database engine memory cache1 50% of host RAM
Recommended number of JET databases per VBO proxy (with default settings) 250
Maximum number of JET databases per VBO proxy (with customized settings)1 700 - 750
1 Contact Veeam support for advanced RAM memory allocation on VBO proxies. For the default VBO proxy, consider allocating
at least 15% of the host RAM for VBO server operations.
Veeam Backup for Microsoft Office 365
infrastructure planning
Typically, the size of an environment dictates the deployment model. The size of an environment is not necessarily related
to the number of Office 365 users that need protected. Rather, it’s based on the number of objects that need to be protected.
The following objects are supported and each one of the items represents one object:
Exchange online and on-premises
• Primary mailboxes
• Archive mailboxes
• Shared mailboxes
• Public folders
• Resource mailboxes (i.e., room, equipment, etc.)
Sites for SharePoint online and on-premises
• Team sites
• Collaboration sites
• Communication sites
• Personal sites
OneDrive for Business online and on-premises
• OneDrive account
For tenant environments larger than 16,000 objects or roughly 4,000 users, the advanced deployment model is recommended.
Another important aspect to consider is the number of restores and the frequency at which these restores happen.
VBO allows two methods for restores:
• Self-service restores using Veeam Explorers

• Web portal restores using RESTFul APIs
The following table shows the typical recommended deployment models based on a certain infrastructure.
Preferences can change based on requirements
Deployment type Simple Advanced Self-service restore RESTFul API
VBO on-premises ✔ ✔ ✔1 ✔5
VBO in public clouds ✔ ✔2 ✔5
VCSPs for single tenants ✔ ✔3 ✔5
VCSPs for multi-tenants ✔ ✔4 ✔5
Self-service restore
The self-service restore option requires users to enable the authentication option where possible to either use a self-generated
certificate or a public one by means of a certification authority. The latter option is preferred and requires internet connectivity
from the VBO server to at least the public certification authority servers.
1For large environments, it is possible to use multiple instances of Veeam Explorers for Microsoft Exchange, SharePoint and
OneDrive for Business, available in VBO and Veeam Backup & Replication to access and recover data. With the latest release
of VBO v4, Veeam Backup & Replication 9.5 Update 4b and above is recommended.
2VBO that runs native in Microsoft Azure, AWS or any other public cloud can use Veeam Explorers for Microsoft Exchange,
SharePoint and OneDrive for Business installed on the same VBO server to access and recover data. Additional Veeam Explorers
can also connect from an on-premises location. Communication between Veeam Explorers and a VBO server is encrypted with
an SSL certificate. A direct connection through VPN may be required if necessary ports on the VBO server running in the public
cloud are not open. With the latest release of VBO v4, Veeam Backup & Replication 9.5 Update 4b and above is recommended.
Service providers can provide access to VBO for their customers, which lets Veeam Explorers for Microsoft Exchange,
3,4
SharePoint and OneDrive, available in VBO and Veeam Backup & Replication, access and recover data stored in pertinent
repositories. In the case of exclusive mode, customers can access their VBO server that runs on a service provider
infrastructure. Customers can also run ad-hoc backup plans where required. In the case of shared mode, customers
can only see existing backups and restores that are pertinent to their tenant by using Veeam Explorers.
RESTful API
The VBO web portal requires the RESTful API option to be enabled to validate and execute commands
(i.e., org/backup/restore/reports/jobs/proxy/repository etc.). In general, this option is used by service providers
for smaller Office 365 tenants where customers have not installed any Veeam solutions that provide Veeam Explorers.
5 RESTful APIs allow customers to create a (typically web-based) VBO portal where users can authenticate and run all available
operations in a VBO console as well. This is the recommended option for:
• Large customers that want to extend self-restores to power users or give single users the option to restore their own data.
• Service providers that are serving tenants who don’t have any Veeam solution installed. In this case, customers should
use a web browser to authenticate against the VBO server.
• A situation where all communications between the Veeam components are secured with an SSL certificate.
VBO server
An important thing that can help planning the VBO architecture is to understand how many objects the VBO server or proxy
needs to work with during backup operations. There are four main object types in VBO: Mail, Mail Archives, Sites and OneDrive.
Knowing the total number of objects who need protection ensures the correct sizing of VBO deployment. It also makes
calculations for future growth more predictable. It’s important to have an estimate of the total number of objects to protect
rather than the number users associated to them. Depending on Office 365 subscriptions, some users may have access
to multiple objects or no objects at all. From a sizing perspective, the number of users is not indicative of the total amount
of data to protect. On the other hand, the total number of mail, mail archive, site and OneDrive objects provide a tangible
parameter to understand how to plan VBO architecture. The number of objects to protect determines the general performance
rather than the total amount of data.
Within an Exchange mail object, there are other types of objects that VBO v4 fully supports, including:
• Discovery search mailbox

• Public folders
• Resource mailboxes (i.e., room, equipment, etc.)
All these objects are classified as mail objects from a VBO perspective.
It’s also important to consider OneDrive for Business objects. From an Office 365 point of view, OneDrive is a special SharePoint
site collection. Although OneDrive for Business shares the same name with OneDrive for the consumer, OneDrive for Business
is the user storage portion of a SharePoint personal site. In general, all data created by Office 365 users can be uploaded
and synchronized in the storage portion that SharePoint provides. All other storage locations and features for personal sites
appear in the regular fashion as standard lists, document libraries, social activities and other SharePoint forms. From a VBO
perspective, sites and OneDrive objects are different. Sites and personal sites are considered to be the same object,
since personal sites are in the same category as sites. Although personal sites and OneDrive share the same storage location
within SharePoint deployments, they effectively serve different purposes. From a VBO planning perspective, this information
is important in determining which VBO proxy and repository to use, since not all data grows equally. This is a good practice
for large environments. In addition, personal sites and OneDrive shares some features but not all features. For example, item
versioning is available on both, but OneDrive requires this feature to be enabled by the SharePoint administrator.
In addition, check-out and check-in is only for SharePoint lists and libraries.
When protecting data, it is possible to choose which objects to include. Since all data doesn’t grow equally, the
recommendation is to create separate jobs that protect different resources by separating user mailboxes and archives from
public and shared mailboxes. Generally, public and shared mailboxes experience a higher growth and change rate compared
to standard mailboxes. The same rule applies to SharePoint and OneDrive. For this reason, VBO provides the option to target
these mailboxes to different VBO repositories, which also benefit from a separate retention policy. For optimal operations,
backup and restore jobs should not exceed the configuration maximums as as detailed in the dedicated section.
VBO proxy
By default, the VBO proxy role is installed on the VBO server. The VBO server can connect to both Office 365 and on-premises
instances to back up and restore data using its built-in role. This is the standard configuration with simple deployments.
For advanced deployments, additional VBO proxies provide the option to scale out to connects available on-premises
and online instances. VBO servers and proxies operate using three important settings:
• Number of threads
• Shared bandwidth consumption across threads
• Internet proxy
Threads are identified as the number of connections or streams that the VBO proxy starts when running a backup or restore
job. By default, the number of threads is set to 64, with a maximum value of 256. The number of threads apply per VBO proxy.
Since each VBO proxy can have different specifications, it’s advised to use different values according to specific needs. Working
with a high number of threads does not always speed up backup and restore jobs; speed also depends on the active Office 365
throttling policy. This throttling policy defines the budget assigned to each connection. In the case of Office 365 environments,
Microsoft dynamically controls this throttling policy by means of Exchange Web Services (EWS) and other APIs in order to
access Office 365 environments. When the use of these APIs become extensive, active streams or threads are throttled, which
slows the overall speed. As a result, it might take a longer time to complete backup or restore jobs. In extreme cases, Microsoft
might even stop these activities until a pause period has expired. When this happens, it is recommended that users don’t insist
on multiple jobs as this will automatically increase the stop time. At the time of writing, Exchange Online PowerShell commands
to review the throttling policies are not available, but they are available for Exchange on-premises. This removes the option to
know the existing values associated with an Office 365 tenant. When experiencing a slow down during backup jobs, it is
recommended that users review the current throttling policy with Microsoft support and ask to resume the default values in
order to accommodate backup jobs and proceed successfully. In the case of Exchange on-premises, custom throttling policies
can be created according to Exchange server resources. VBO will consume these resources according to defined policies.
Another setting that operates on the VBO proxy level is the shared network bandwidth.. For each VBO proxy, it’s possible
to assign a custom value expressed in Mbps, MB/s and KB/s. This chosen value will then be shared across a number
of chosen threads on the same VBO proxy. When not configured, the VBO proxy will use all available network bandwidth.
It is recommended that users limit bandwidth when the same network is shared across different applications,
The VBO proxy default settings are suitable for most deployments. For larger environments and service providers in shared
mode, it is possible to tweak the settings and even hardcode the maximum RAM memory and the number of JET databases
(i.e., repository files) that the VBO proxies can work with.
In general, the maximum number of databases opens with the first backup when an initial “full” is performed.
On subsequent incremental backups where no changes have occurred from past years, pertinent connections to older
JET databases are closed. Each JET database corresponds to a year folder. For example, 10 organizations that back up data
with a retention policy of 10 years each will create and open 100 JET databases during the first full backup in the assigned
repositories. The number of databases also varies based on the retention policy type. The section “Configuration maximums”
provides more details on the number of JET databases that are supported. This also includes RAM memory management
from a VBO proxy and repository perspective.
For large deployments, advanced customizations on RAM memory allocations per VBO proxy can be configured
through Veeam support.
For organizations that implement web proxy configurations, it is possible to specify the same settings for both the VBO server
and additional VBO proxies. Typically, in simple deployments, the internet proxy configuration is set up directly in the properties
section of the VBO server.
Large organizations and service providers who adopt the advanced model can use specific web proxy configurations over
separate VBO proxies. By default, web proxy configuration is inherited and refreshed every 48 hours directly from the VBO
server. Specific VBO proxies can override the main configuration according to requirements. In addition, transparent, non-
transparent and with-authentication web proxy configurations are supported.
VBO repository
In a simple deployment, the VBO server protects and stores data using its built-in role into local storage.
For advanced deployment, when configuring additional VBO repositories, the following considerations apply:
• The VBO repositories are always associated to one VBO proxy at a time. However, one proxy can be associated to multiple
VBO repositories instead.
• For the best performance, it is recommended that VBO repository files should use either local or DAS types of storage.
Although SMB shares and iSCSI is supported, the storage with the highest throughput available should be used.
This will greatly help backup jobs that require more IOPS and bandwidth. It is worth noting iSCSI generally provides
better performance over multiple small files compared to SMB, which is a likely scenario during backup jobs.
• VBO repository files come in the format of database type (i.e., Microsoft JET database). The storage used for repository
files should not have encryption, deduplication and compression enabled on OS and volume levels. Native JET Database
compression is employed during backup jobs.
• The maximum supported size per VBO repository is 64 TB per single file. Since repository files are database files, an extra
10% of free space should be provisioned. This ensures that the database can run internal operations like checkpoints
and log truncation smoothly along with log files.
• Creating additional VBO repositories reduces the risk of growing large single repositories. For example, it’s possible
to create separate VBO repositories for emails based on business units or location. Large VBO repositories are optimized
against intensive I/O sequential reads at the expense of requiring more disk space. During backup operations, data
is written into transaction files before being committed. During restores, since no caching occurs on disk, operations
run in memory. Larger VBO repositories require more memory to be available.
• Each VBO repository can also have separate retention policies, which can be item-level or snapshot based.
Storage provisioning for Microsoft Office 365 backup data
Multiple VBO repositories provide users the option to increase the space available to store data and offer different retention
policy configurations. Understanding the backup storage requirements for Office 365 data is helpful when designing a backup
infrastructure that is sustainable long-term. While there are different methods that can help address the growth and change
rate for Office 365 data, planning for accurate sizing is a complicated process given the complexity and the number of variables
involved. The following sections cover the basics for supported data retention types and suggest formulas to determine the
amount of storage that should be allocated to VBO repositories for the desired retention period. The formulas provide an
indication of the storage growth over the period of desired retention. These formulas are based on the current figures available
in the Office 365 administrative portal and PowerShell commands for the on-premises equivalent.
Supported data retention types

The retention policy is a configuration that applies to VBO repositories directly, not to jobs. This is a global setting
and it affects all backup jobs that use the same VBO repository. VBO offers two types of retention policies:
I tem -level and snapshot-based .
Item-level retention policies operate in two ways:
• During the first backup, objects that included within the retention policy period are evaluated based on their last modification
date. For example, by setting a retention policy of three years, the backup job will automatically include all the items in which
this value is below three years. Thus, this will leave out anything older than three years.
• At selected intervals and based on a schedule, the VBO repository will apply the retention policy directly on repository files.
Based on the age of the data and according to the last modification date, all data that’s older than three years will be
automatically purged from the VBO repository. At any point in time, the repository will only include a rolling time window
based on the retention policy set for the specified period.
The snapshot-based retention policy operates in two ways:
• During the first backup, all available objects are included in the backup job regardless of their creation, deletion
or modification time. The first backup is a full backup. This is followed by incremental backups, which only add changes
like new, delete and update items from the previous job.
• At selected intervals and based on a schedule, the VBO repository will then apply the retention policy directly to backup files.
This provides a point-in-time (PIT) approach.
When comparing the item-level to snapshot-based approaches, the following applies:
• The initial storage requirements for item-level backups are lower when compared to a snapshot-based retention policy.
• Extending the retention period will consume extra space within the VBO repository.
• Reducing the retention period will not shrink the size of the VBO repository. Rather, it will create free empty space
and use that before growing again.
• PIT items and backups are automatically deleted once the retention period or dependencies with other
VBO repositories or jobs have expired.
Other important aspects to consider for both retention styles include the following:
• When stale data is purged from the backup file, the current size of the VBO repository database file will not shrink.
• Free or emptied space inside the backup repository file will be used before its size is increased.
• VBO repository database files can be removed only when all backup data for such repositories have expired and no incoming
data from other backup jobs are arriving.
• Retention policy is a setting on the VBO repository level. When multiple backup jobs are using the same VBO repository,
all backup data for these jobs will be subject to the same retention policy. For different retention policies, the best practice
is to use different VBO repositories.
• The retention policy for data that should be included in the backup can be specified in number of years from one to 99,999 days.
• The retention policy for data to be deleted can be scheduled on monthly and daily combinations including:
• Every day
• Only work days
• Weekends
• A specific day of the week/month
• A specific week of the month
• Your retention policy can be disabled by selecting the option “keep forever”.
In a scenario where data should not be deleted from the retention policy and archived for even longer periods,
it is recommended that users follow considerations on how to protect the VBO deployment.
Microsoft Exchange backup
Office 365 native tools provide limited information to help make detailed calculations. In the case of Exchange online,
it is recommended that users retrieve information from the Office 365 administrative portal in the report and usage sections,
particularly, the current storage used and the storage trends. In the case of Exchange on-premises, the PowerShell commands
provide more flexibility. In fact, at the time of writing, some PowerShell command-lets and parameters that are available
for on-premises installations are not available for the equivalent online instances. For example, this includes the commands
to query the throttling policy as covered in the “Microsoft throttling policy” section as well. These cmdlets are available
in on-premises Exchange and in cloud-based services. Note that some parameters and settings may be exclusive
to one environment or another.
The table below shows the most common Exchange PowerShell commands used to retrieve this information:
PowerShell command Exchange on-premises Exchange online
Get-Mailbox ✔ ✔
Get-MailboxStatistics ✔ ✔
On this basis, a suggested formula to help calculate storage requirements includes the following, which is applicable for both
item-level and snapshot-based retention policies. In addition, these provide estimates for local VBO repositories. Blob storage
calculations will be different.
For primary mailboxes:
(Current prim ary m ailbox es total size) + ((Daily change rate x 2) * (Days of retention)) + (10% w orking area)
For archive mailboxes:
In case the VBO backup plan should include Exchange archive mailboxes, the total storage requirements
should include the following:
(Current archive m ailbox es total size) + ((Daily ChangeR ate) * (Days of retention)) + (10% w orking area)
It is worth noting that different VBO repositories can be used to store different backups. This provides the flexibility
of using cheaper storage for long-term backups in archive mailboxes and a better performing one that’s dedicated to backing
up primary mailboxes. Other mailbox types like shared, public and resource mailboxes can use the same primary mailbox
formula with a separate calculation.
Formula explained:
Total size of current primary mailboxes = The sum of all primary mailbox storage. In the case of Exchange on-premises,
the PowerShell command “Get-Mailbox” provides this information.
Total size of current archive mailboxes = The sum of all archive mailbox storage. In the case of both Exchange
on-premises and online, the PowerShell command “Get-Mailbox -Archive” provides this information.
The following is a sample command that will return the size of all primary mailboxes.
A similar one can be used for archive mailboxes as well as with the pertinent “-archive” option:
Get-Mailbox | Get-MailboxStatistics | Select-Object DisplayName, ItemCount, TotalItemSize | Format-Table –autosize
In the case of Exchange online, the admin page on reports > usage > Exchange > mailbox usage >
storage provides this information as an example:
Daily change rate = The value that defines the changes that occur on Exchange mailboxes, including deletion and retention
activities. This value needs to be multiplied by two (for primary mailboxes only) and by days of retention desired. Typically, this
means a year or longer, depending on requirements. The following step helps to determine the daily change rate:
((Ending size in period) - (Starting size in period)) / (N um ber of days in period)
In the sample below, depending on the amount of available details, it is possible to calculate the daily change rate.
The example shows a period of 30 days. The value of the daily rate needs to then be multiplied by the days of retention
to obtain growth rate information:
Days of retention = The period of time in which the content is retained in the VBO repository before getting deleted by the
VBO retention policy.
Working area = The free space on the file system where VBO repository database files run and commit transactions during
backup jobs and retention policy schedules. In general, this free space is calculated as the 10% of the current total size.
Microsoft SharePoint and OneDrive backup
The Office 365 administrative portal provides basic metrics that can be used to calculate the storage necessary for a backup of
user-created content. While the available information in the Office 365 portal shows the current storage usage, it is possible for
you to combine this information with storage trends to understand the future requirements from a backup storage perspective.
The numbers and formulas in this document are not set in stone. The best practice is to review storage trends on at least a
quarterly basis in order to quickly identify future requirements for backup storage. The following sections cover the formula in
more detail for both SharePoint online and OneDrive for Business.
SharePoint online
Available in the Office 365 portal > reports > usage > SharePoint > site usage > storage.
The suggested formula to calculate VBO backup size, including future growth is:
(Ending size in period) + ((Daily ChangeR ate) * (Days of retention)) + (10% w orking area)
Daily change rate = The value that defines the changes that occur on SharePoint sites, including deletion
and retention activities.
The following step helps determine the daily change rate:
In the sample above, depending on the number of available thresholds, it is possible to calculate the daily change rate.
The example shows a period of 30 days. The value of the daily rate then needs to be multiplied by the days of retention
to obtain the desired growth information.
Days of retention = The period in which content is retained in the VBO repository before getting deleted
by the VBO repository retention policy.
Working area = The free space on the file system where VBO backup repository database files run and commit transactions
during backup jobs and retention policy schedules. In general, this free space is calculated as 10% of the current total size.
A good practice that helps limit the overall backup size for SharePoint data is to reduce or set a threshold to document libraries
and list item versions. For example, setting five major versions on SharePoint lists and libraries can help reduce the initial
storage footprint which can be beneficial for backup storage as well. Some departments may consume the five versions quicker
when compared to other ones that, for example, slowly release new versions of the documents. Every department is different,
and its recommended that users find a standard value across all libraries, which also helps SharePoint perform more efficiently.
Enabling and leaving unlimited versioning should be avoided for the same reasons mentioned above.
OneDrive for Business
Available in the Office 365 portal > reports > usage > OneDrive > usage > storage.
The suggested formula to calculate the VBO repository backup size is:
(Ending size in period) + ((Daily ChangeR ate) * (Days of retention)) + (10% w orking area)
Daily change rate = This value defines the changes that occur on OneDrive for Business, including
deletion and retention activities.
The following step helps determine the daily change rate:
In the example above and depending on the number of available thresholds, it is possible to calculate the daily change rate.
The example shows a period of 30 days. The value of the daily rate needs to then be multiplied by days of retention to obtain
the desired growth information.
Days of retention = The period in which content is retained in the VBO repository before getting deleted
by the VBO repository retention policy.
Working area = The free space on the file system where VBO repository database files run and commit transactions
during backup jobs and retention policy schedules. In general, this free space is calculated at 10% the current total size.
A good practice that helps reduce the overall backup size and increase VBO backup job performances is to target OneDrive
backups to separate VBO repositories. Typically, OneDrive backups can be quite large, which means that bigger and cheaper
VBO repositories would be ideal. Performance is not affected by VBO repository size. For larger environments, servers that run
the VBO proxy and Veeam Explorer roles require more RAM memory as covered in the VBO configuration maximums section.
Considerations about Blob Storage
Traditionally the common practice for VBO is to store backup data to disks. This can be in the format of DAS, SAN and SMB
storage. The VBO backup repositories use an optimized Microsoft JET database format to store the data. This means that
backup data is stored in a database format, making it less suitable for other storage types like object storage and data
deduplication targets. The native VBO repository format allows for swift restores without the staging or caching of any content.
In addition, the format provides the ability to perform sophisticated searches and queries across the entire content for
eDiscovery purposes. A built-in mechanism also allows users to keep or discard backup data until the retention period expires.
Disk performs the best as tier-one storage. As of VBO v4, a new “extended VBO repository” option is available. It allows users
to back up Office 365 data directly to Blob storage. VBO uses a cache to reference metadata before storing actual data to Blob
Storage. Thanks to metadata references stored in the cache, the restore process will download only required data blocks that
reduce egress operations and charges to a minimum.
Blob Storage as tier-one: Extended backup repository
For customers and service providers who want to store data directly to their Blob Storage of choice,
the following are supported:
Microsoft Azure Blob Storage
• Supports hot and cold tiers
Amazon S3
• Supports standard and Infrequent Access (IA)
S3 compatible
• Supports any S3 compatible (with signature v4) online and on-premises
IBM Cloud Object Storage
• Adds support for both S3 storage on premises and IBM public cloud
The extended VBO repository combines the advantage of a standard VBO repository running as a cache with object storage
where data is stored on virtually infinite storage for long-term retention. When creating the extended VBO repository,
the following applies:
• The cache includes metadata information for the backup content and not the data itself.
• The cache is created and updated during each backup session.
• The cache is stored in a JET database. For the best performance, it is recommended that users place the cache on DAS
or SAN storage. In general, for growth of up to 2% for Exchange data and up to 6% for SharePoint and OneDrive,
based on source size.
• VBO includes a replication engine which copies cache content to the Blob Storage.
• VBO reads information from cache and presents content available for restore without accessing Blob Storage online.
This limits numbers of operations for which public cloud providers charge for.
• VBO reads from Blob Storage only the content that should be restored as opposed to mount and read
the entire backup content.
• The cache is used to recover and extend VBO repositories in case of disaster. An automatic synchronization process rebuilds
the metadata information for all protected data.
• Backup content is compressed before sending it to Blob Storage.
• At-rest encryption is available for Blob Storage.
• Extended VBO repositories support both item-level and snapshot based retention policies.
Blob Storage as tier-two: Use the integration with Veeam Backup & Replication
In general, Blob Storage is used for offsite copies of the data and long-term retention requirements. In such a scenario,
Blob Storage acts as a tier-two storage. The amount of backup data is growing over time and disk storage presented
to the VBO proxies may not be enough to cover the desired requirements. As outlined in the section that covers how
to protect the VBO infrastructure and its backup data, using Blob Storage as secondary storage targets is a valid addition
to a data protection strategy for Office 365 data. The diagram below shows an example of how to use both disk
and Blob Storage types as two separate tiers of storage that can retain data over longer periods.
• VBO is configured to protect Office 365 data.

Protect Office • Data is stored on disk VBO repositories on DAS, SAN or SMB shares.
365 data
• VBO retention policy is set according to requirements like SLAs, application

type and data size.
Define short- • Typically tier-one disk storage is provisioned based on initial requirements
term retention like days or months.
• Veeam Backup & Replication protects VBO infrastructures and data.

• Veeam Backup & Replication sends and manages backup copies to tier-two
Define long- storage (i.e. Blob Storage).
term retention
When protecting the VBO infrastructure with Veeam Backup & Replication, the following applies:
• The first backup of a VBO server and its backup data is a full backup.
• The following backups of VBO are incremental.
• Any VBR PIT can be used to granularly restore any VBO server file.
• Any VBR PIT can be used to granularly restore from any VBO backup file.
• All VBO backups benefit from compression, deduplication and encryption.
• VBO runs application and crash-consistent backups of the VBO server.
• The ability to keep independent, separate and multiple copies to a Blob Storage location of choice.
• The ability to send copies to other storages like DAS, SAN, NAS, tape and deduplication.
• The ability to seamlessly restore content from copies in any location.
Operational guidelines for backup and restore jobs
When planning VBO server deployment, the following should be considered:
Steps: Description:
Determine which objects to include This can be a combination of:
• Primary mailboxes
• Archive mailboxes
• Public folders
• Resource mailboxes
• OneDrive accounts
• SharePoint sites
• Microsoft Team sites
• Personal sites
Verify the number of users Based on the number of users and the total number
of objects, it is possible for users to plan the
number of VBO proxies required to complete backup
jobs based on the maximum number supported per
VBO proxy and instance.
Create a separate job for Exchange resources Resources include:
• Public folders
• Equipment
• Room
Create a separate job for SharePoint sites This can be a combination of:
• All SharePoint sites and templates

• Team sites
• Personal sites
Create a separate job for OneDrive resources OneDrive backups will consume more space and
time to complete compared to Exchange and
SharePoint backups. The best practice is to create
separate backup jobs using different VBO
repositories, especially with large or frequent
OneDrive users.
Designate multiple backup accounts For SharePoint Online and OneDrive for Business,
it’s recommended that users create auxiliary
accounts for backup jobs. Additional accounts
increase the performance and reduce the risk of
throttling. These accounts require pertinent
Steps: Description:
permissions to protect SharePoint and OneDrive
data but not necessarily an Office 365 subscription
license. The best practice is to add auxiliary backup
accounts in multiples of eight (eg. 8,16,24).
Determine the folder types of Exchange backup jobs This is a global setting which allows to include:
• Drafts
• Deleted items
• Junk emails
• Outboxes
• Sync issues
• In-place and litigation hold items
Determine the retention policy associated with Data is stored in databases divided by years.
backup jobs Longer retentions can take up more space but will
not grow data from previous years. Data exceeding
the retention policy is automatically removed.
Determine the retention policy type: Item-level or Item-level retention policy types require an initial
snapshot-based storage footprint that’s lower compared to
snapshot-based retention, as it’s based on the last
modification date of the items.
Snapshot-based is a PIT of the entire content.

Initial footprints on storage will be higher when
compared to item-level retention.
It’s not possible to change the retention type once

its selected. If required, backup data can be moved
to a new repository with a different retention types
using PowerShell cmdlets.
Removing content from the backup job does not When removing mailboxes or other objects from
shrink the backup file the backup job, the VBO repository will not remove
them from the VBO repository. It will mark that
space as reusable. As soon as new objects are
added, the marked space will be used again
before it increases.
Consider backup jobs outside business hours • To reduce the risk of throttling, backup jobs
should be scheduled to run during off-peak
hours as standard Office 365 operations already
consume the budget allowance allotted
per tenant customer.
• Increase the amount of time for retry/fails.
This allows users to reclaim quicker resources
that are assigned to the Office 365 tenant.
Backup job considerations
VBO provides users with the option to create and configure several jobs for multiple organization types, including online,
on-premises and hybrid environments.
While each VBO deployment can be different, there are several considerations that should be considered when creating
VBO backup jobs.
• All backup jobs are encrypted in-flight using the SSL certificates present on the VBO server. These are self-signed certificates
that are used during the VBO deployment. It is possible to exchange existing certificates with new ones, either self-generated
or provided by a certification authority at any time.
• It is possible to dictate which objects should be included as part of the plan: mail, mail archive, discovery search mailboxes,
shared folders, public folders, resource mailboxes, OneDrive for Business, sites and personal sites. These objects don’t
necessarily grow at the same rate or have the same retention requirements. For this reason, it is recommended that users
create different backup plans that target different objects.
• By creating different plans, VBO allows for different schedules and repositories where users can store data
(i.e., creating plans based on a gold, silver and bronze SLAs).
• Using multiple repositories allows for separate retention policies.
• To help reduce the space requirement for backup storage, VBO provides users with the option to automatically
include or exclude specific folder types:
Exchange:
• Drafts
• Deleted items
• Junk emails
• Outboxes
• Sync issues
• In-place hold items
• Litigation hold items
OneDrive:
• Folders and subfolders
It’s important to mention in-place and litigation hold items. When these features are enabled, copies of the original items
are kept within the same mailbox storage in a hidden area called recoverable items. Depending on the length of the legal hold
and Exchange retention policy, such items might get permanently deleted by the Exchange mailbox folder assistant (MFA)
as an automatic process. By including such folders in a VBO backup plan, this eliminates the risk of losing access to these
items where a legal hold is applied.
Restore job considerations
Veeam Explorers coordinate with VBO proxies to perform the restore and export operations as highlighted
in the VBO architecture section.
Veeam Explorer for M icrosoft Ex change allows users to:
• Export content from live unmounted Exchange databases to another location.

• Restore mailbox items directly from VBO backups (.adb).
• Connect to separate VBO servers.
• Self-service restores for mailbox content, available only to customers connected to a VCSP partner.
• In-place and out-of-place restores to on-premises and online instances for any mailbox item.
• Export in .msg and .pst formats.
• Export as an attachment using the Microsoft send functionality.
Veeam Explorer for M icrosoft ShareP oint allows users to:
• Export content from live unmounted SharePoint content databases to another location.
• Restore SharePoint sites to the original location with permissions and versions.
• Export from standalone VBO SharePoint backups (.adb file).
• Connect to separate VBO servers.
• Restore site collections, sites and subsites.
• Restore standard and custom lists, libraries, items and documents.
• Restore content down to specific versions, both major and minor.
Veeam Explorer for M icrosoft OneDrive allows users to:
• Export content from live and unmounted SharePoint content databases with OneDrive data to another location.
• Export from standalone VBO OneDrive backups (.adb fle).
• Restore OneDrive folders and content to other OneDrive locations.
• Export as a .zip file or file the content.
For each one of these operations, Veeam Explorer is mounting the requested database in read-only mode, and then presenting
the content through an explorer from which it is possible to restore back to the original location or a different instance.
Office 365 throttling policy
This section provides an understanding of the different throttling policies for online and on-premises environments.
Knowing how default Microsoft throttling policies work helps create a better design and implementation of the VBO architecture.
Exchange Online
Throttling in Exchange Online helps users ensure server reliability and uptime by limiting the amount of server resources
that a single user or application can consume. This approach ensures that resources are available for all users and applications
that access Office 365 servers online. Throttling proactively regulates the overuse of server resources that may affect the
service reliability and functionality. Exchange online constantly monitors the health of Office 365 infrastructure resources,
including mailbox databases. EWS connections are throttled proportionally when high-load factors are detected and can
degrade the performance of these servers. Throttling is operated automatically and is transparent to the user or application.
Even within throttling limits, slowdowns can be experienced until the health of the resource is back to operational levels.
EWS APIs operate with Exchange objects like mailbox and pertinent items by using three different levels of access:
• Owner
• Delegation
• Impersonation
The type of access (i.e., owner, delegation and impersonation) makes a difference in how the limits of the throttling policy
are applied. Based upon this type of access, the active connections to the Exchange objects will either be charged to the service
account (owner and delegation) or against the mailbox that’s being accessed (impersonation).
EWS owner access to Exchange mailbox

When accessing the mailbox with the owner account, it will be charged for each connection to the mailbox. The VBO application
by default does not use this level of access.
EWS delegation access to Exchange mailbox

When using delegation access like folder-level and full mailbox delegation access, it will cause connections to be charged
against the service account. Often applications that use this method of access are processing many mailboxes, so there’s a
chance of getting throttled during high activity periods with multithreaded calls. The VBO proxy configuration allows users
to set the desired number of concurrent threads. More threads can process more folders and items and can consume
EWS resource budgets faster. The VBO application might use this method if the impersonation access is not enabled.
When adding an organization to the VBO server, the impersonation role is automatically configured. Alternatively,
this role can also be configured using Exchange organization PowerShell command-lets.
EWS impersonation access to Exchange mailboxes

Access using EWS impersonation will cause the connection count to be charged directly to the budget of the mailbox being
accessed. Since mailboxes generally have a high limit for simultaneous connections under the default policy limit, the chances
of being throttled on active connections are very low. The exception to this rule with load-intensive applications against one
mailbox. Throttling policies monitor budget rate consumption in addition to active connections. EWS APIs also offer incremental
reading and writing capabilities when accessing content. This helps reduce the amount to time it takes for incremental backups
to be added to newly created and changed folders and other items.
Exchange online throttling policies are controlled only within Office 365 data centers as these are responsible for the uptime
of applications that are running in the infrastructure. In general, when experiencing throttling during backup jobs or restores
of large amounts of data to the Exchange online service, the following should be verified:
• The application impersonation role is enabled

• The view-only configuration role is enabled
• The view-only recipients role is enabled
• The mailbox search role is enabled
• Backup jobs follow the general recommendations
• The total number of objects do not exceed the values as per VBO configuration maximums
• The number of concurrent worker processes or threads are not too high as they might hit the maximum number
of connections quicker and trigger throttling policies. More information on thread configurations are covered
in the VBO proxy section.
• Jobs are configured with retry-failed and wait attempts of 20 minutes or more.
Ultimately, in the case of Exchange Online, resources are constantly monitored and the EWS budgets assigned to each tenant
or organization change accordingly. Such resources cannot be controlled externally but can only be consumed within the limits
defined by the Microsoft throttling policy. Should throttling occur, it goes from an overall speed reduction, for backup and
restore jobs, not for mailbox access and usage, to a pause period. In severe cases with the throttling policy applied, online
resources may show a “503 error – Service unavailable” message. In such cases, it is recommended that users open a ticket
with Microsoft support in order to reset the throttling policy to a default value.
SharePoint Online and OneDrive for Business

Like Exchange Online, SharePoint Online and OneDrive for Business use throttling to maintain optimal performance and
reliability of their respective services. In this case, throttling limits the number of user actions and concurrent calls by using
CSOM and RESTful APIs by script or code to prevent the overuse of shared resources. This guarantees stable and predictable
performances for multiple tenants who use SharePoint Online and OneDrive for Business services. While in general it is rare
for a user to get throttled, the execution of custom code from applications may increase or exceed the allowed resource quota.
The Office 365 services are robust and designed to handle very high volumes. Usually, online throttling policies are caused
by custom code that runs intensive tasks over long periods. In general, when experiencing throttling during backup jobs
or the restores of large amounts of data to the SharePoint Online service, the following actions should be performed:
• Backup jobs follow general recommendations

• Reduce the requests by limiting the concurrent number of threads per VBO proxy
• Span the jobs over longer periods
• Add auxiliary backup accounts in multiples of eight
• Use retry failed and wait for attempt object processing in the job configuration. The longer the better, as the throttling
policy includes recharging times to replenish the tenant budget. Every 20 minutes or more should be enough to recharge
the allocated budget.
• Run the jobs during off-peak hours. This avoids contenting the same budget with native OneDrive clients that use the same
SharePoint online APIs (SPO) to constantly sync content between the on-premises environment and the Office 365 cloud.
Exchange on-premises
Custom throttling policies can be created and enforced for on-premises applications like Exchange servers. The default
throttling policy, access to throttling policies and throttling policy configuration differs between online and on-premises
deployments. While online deployments cannot be controlled or monitored outside Office 365 data centers, on-premises policies
can be customized. Note that specific throttle setting values are only accurate for specific versions of Exchange. Because these
values vary across versions and because administrators can change the default throttling policies for on-premises deployments
based on different requirements, this document does not provide the default setting values. For those who want to explore,
review and configure the Exchange on-premises throttling policies, there are built-in PowerShell commands available only
for this type of deployment. These include:
• Get-ThrottlingPolicy
• Get-ThrottlingPolicyAssociation
• Set-ThrottlingPolicy
• New-ThrottlingPolicy
• Remove-ThrottlingPolicy
Although these PowerShell commands are available for on-premises deployments of Exchange that provide the option to create
custom policies, they should be used with caution, considering the current workload in conjunction with the desired resources
to allocate for backup jobs to complete successfully. It is highly recommended to configure and enable the impersonation role
to be used with the service account that will run backup and restore jobs. For hybrid deployments, it is recommended to use
the same service account. From this perspective, the best practice is to configure the Azure AD connect tool (AAD) which keeps
the chosen service account attributes in sync in both Active Directory forests: The one running on-premises and the one
running in Microsoft Azure.
Veeam Backup for Microsoft Office 365 protection
As a best practice, it is important to protect VBO servers against accidental loss. Protecting VBO deployments ensures
availability for its infrastructure components and more importantly for the data in the VBO backup repositories.
In addition, protecting the VBO repository data helps achieving the industry 3-2-1 Rule:
• Three copies of the data

• Stored in two different types of media
• One of those types of media should be either offsite or offline
A VBO deployment can be on either a physical or virtual environment. As with both virtual or physical server installations,
Veeam Backup & Replication offers all the tools for application and crash-consistent backups of VBO deployments.
Each VBO server and proxy installations include a specific Veeam VSS writer:
“Veeam Backup for Microsoft Office 365 writer”
• Writer ID: {dbc7d206-2f04-429a-80f5-dbb23da79372}
This VSS writer ensures application and crash-consistent backups of the VBO infrastructure components. Even while the
VBO server and proxies are running backup and restore jobs of Office 365 data. Protecting a VBO deployment with
Veeam Backup & Replication offers the following advantages:
• Ensures swift VBO component restores like ConfigDB, ProxyDB and associated files.
• Performs granular restores of content using VEX, VESP and VEOD components available in the Veeam Backup & Replication
server for Veeam Backup & Replication 9.5 Update 4b and higher.
• Verifies the recoverability of the VBO server installations by leveraging built-in Veeam SureBackup® jobs for VBO.
Protection planning must also include the additional VBO proxy servers and repositories. Should the VBO repository use SMB
shares, such shares need to be backed up separately. Configuration and proxy database files on the VBO server and VBO proxy
installations are very important. They include all the information and details for the VBO infrastructure. Restoring these
components from a backup is the quickest way to maintain the existing running configuration without affecting the rest
of the deployment and its jobs. Protecting a VBO server and its infrastructure is critical with advanced deployments.
In these scenarios, one VBO server operates with different VBO proxies and repositories for different tenants concurrently.
Effectively, the same proxy can be shared across separate tenants with different jobs. Having a protection plan that covers
all components allows for agile recoveries of all VBO major components, including VBO server, proxies and backup data
in the repositories.
Protecting the VBO deployments using Veeam Backup & Replication solution allows users to send and manage independent
copies to separate storage tiers for longer retention. Due to increasing popularity, a special mention goes to Blob Storage,
either in private or public clouds. Blob Storage is a good candidate for long term retention. It is possible to use this storage tier
for PIT copies of the VBO deployments from Veeam Backup & Replication which includes major components and backup data.
The diagram below shows an example of how to protect a VBO deployment by using a separate tier:
• Production data is sitting in an Office 365 cloud and is available to users.

• Production data is subject to predefined Office 365 retention policies.
• Only short-term protection is natively available.
Production
• Limited visibility for deleted data in advanced stages (for non-admin users).
data
• VBO in the primary data center takes a tier-one primary backup with custom retention.
• Data is available to users from both the cloud and primary data center.
• Ability to restore content to the cloud.
Primary copy • Ability to restore content in a separate location.
• VBR protects VBO. VBR sends backup to Blob Storage (tier-two) for longer retention or
increased storage.
• VBR sends backup to Blob Storage (tier-two) for longer retention or increased storage.
Secondary • VBR restores Office 365 content directly from Blob Storage with Veeam Explorers.
copy • VBR restores content from PIT older than retention sets in tier-one primary backup.
No ingress or egress charges are associated with Veeam Backup & Replication when sending or restoring backup data
from Blob Storage in the public cloud. Egress charges may be charged by the public cloud provider of choice.
Veeam Backup & Replication supports S3-compatible Blob Storage starting from “signature v4” and above. Organizations
can benefit from local S3-compatible storage in their primary and secondary data centers when configured in conjunction
with Veeam Backup & Replication.
Summary
Office 365 is the fastest growing digital collaboration platform today. It empowers users by providing them with access
to cloud-based applications for productivity. It offers a seamless experience while the data is located on-premises and online.
Today’s customers need to always have data available.
Office 365 meets the most stringent criteria for compliance and technical enablement by making sure that customers’ data
can always be operated by multiple devices and different locations. As a public cloud provider for Software-as-a-Service
(SaaS)-based solutions, Office 365 offers uptime for infrastructures rather than data. Microsoft manages the infrastructure
and customers manage their data — even when it’s hosted by a cloud provider. The owners of this data need to supply a plan
for data protection and availability. Lots of things can disrupt service availability such as hardware failure, natural disasters,
human error and even unsolicited activities from rogue apps or departing users.
VBO is a solution built from the ground up, and offers both a short- and long-term protection plan that avoids data loss
and increases the availability of data across any cloud and platform. The benefits of VBO include:
• Management of multiple organizations from the same installation. In fact, these can be any combination of on-premises,
online and Office 365 hybrid deployments.
• Facilitation of management when protecting data. When creating backup jobs, it is possible to choose what to protect
and how long data should be retained. This makes it easier to manage your own retention policy.
• Providing options to browse and search with eDiscovery capabilities, which helps to pinpoint specific content.
This is particularly useful as it significantly reduces the RTO to restore any Office 365 data to the original location
or a different platform. Such functionality is already helping customers dictate which content should be migrated between
on-premises and online instances.
• Integration with multi-tenant infrastructures from VCSP partners who already offer BaaS and DRaaS, which provides
additional value for their customers.
• Storage agnostic approach: backup data can be stored on DAS, SAN, SMB and Blob storage within private and public clouds.
Features at-rest encryption for Blob Storage.
• Simplified deployment for cloud-first companies.
• Faster backup performance with latest APIs.
About Veeam Software

Veeam® is the leader in Backup solutions that deliver Cloud Data Management™. Veeam provides a single platform
for modernizing backup, accelerating hybrid cloud and securing your data. With 365,000+ customers worldwide, including
81% of the Fortune 500 and 66% of the Global 2,000, Veeam customer-satisfaction scores are the highest in the industry
at 3.5x the average. Veeam’s global ecosystem includes 70,000+ partners, including HPE, NetApp, Cisco and Lenovo
as exclusive resellers. Headquartered in Baar, Switzerland, Veeam has offices in more than 30 countries. To learn more,
visit https://www.veeam.com or follow Veeam on Twitter @veeam.

Guide Veeam Backup Microsoft Office 365 v4

Uploaded by

Document Information

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

Guide Veeam Backup Microsoft Office 365 v4

Uploaded by

Copyright:

Available Formats

Veeam Backup

for Microsoft Office 365

(A) DNS host address record

AMI Amazon Machine Image

API Application Programming Interface

AWS Amazon Web Services

Blob Binary Large Object file

Cmdlet PowerShell command let

CIFS Common internet file system

CPU Central processor unit

DAS Direct attached storage

DNS Domain name server

DRaaS Disaster Recovery as a Service

EC2 Elastic compute cloud

EBS Elastic block storage

eSATA External serial advanced technology attachment

FQDN Fully qualified domain name

HBA Host bus adapter

Ipv4 Internet protocol version 4

Ipv6 Internet protocol version 6

iSCSI Internet small computer systems interface

JET Database Microsoft JET blue database

MSG Microsoft Outlook message file

PST Microsoft Outlook personal storage table

PTR DNS host address pointer record

RDM Raw device mapping

RPO Restore point objective

RTO Restore time objective

S3 Simple Storage Service (Amazon)

SAN Storage area network

SMB Server message block

SSL Secure socket layer

USB Universal serial bus

VBO VBO Backup for Microsoft Office 365

VBO Proxy VBO Backup for Microsoft Office 365 proxy

VBO Repository VBO Backup for Microsoft Office 365 repository

VBO Server VBO Backup for Microsoft Office 365 server

VCC Veeam Cloud Connect

VCSP Veeam Cloud & Service Provider

VBR Veeam Backup & Replication™

vRDM Virtual raw device mapping

Deployment options VBO

Service provider for single-tenant (exclusive mode) ✔

Service provider for multi-tenant (shared mode) ✔

Public cloud deployments

Service providers for multi-tenants (shared mode)

• Full isolation on the tenant level

These are common principles to all deployment types:

The VBO architecture consists of four main components:

The VBO server includes the following main components:

a) In-place and out-of-place restores:

• Attachments and Microsoft Outlook *.pst and *.msg files

Other use cases include browsing, searching and exporting content.

OneDrive for Business backup

c) Search for content

DNS name resolution

• Provide a static IP address to the VBO server

Additional proxy deployment

Microsoft Windows Domain membership

Anti-virus and HIPS

Path VBO server VBO proxy

VBO server VBO proxy server

Installation folder %ProgramFiles%\Veeam\Backup365 %WinDir%\Veeam\Backup365\Proxy

Data folder %ProgramData%\Veeam\Backup365 %ProgramData%\Veeam\Backup365

• Attachments and Microsoft Outlook .pst and .msg files