(click to expand table of contents)

• 2. Backup for Office 365 Sizing and Architectural Components
  • 2.1. Veeam Office 365 Data Sizing Assumptions
  • 2.2. Azure Architecture Compute Requirements
    • 2.2.1. VBO365 Management Compute Requirements
    • 2.2.2. VBO365 Proxy Compute Requirements
    • 2.2.3. Suggested Azure VM Sizes
    • 2.2.4. User to Server Architecture Translation Table with VM Sizes
  • 2.3. VBO365 Repositories
    • 2.3.1. Block Storage Requirements (Metadata) and Object Storage (Backup Data)
    • 2.3.2. Virtual Network Service Endpoints

2. Backup for Office 365 Sizing and Architectural Components

Sizing of a Veeam Backup for Office 365 (VBO365) environment depends on the number of objects the system will protect. Objects are defined as a mailbox, archive mailbox, shared mailbox, OneDrive, Personal SharePoint site, and a Shared SharePoin site. The number of users can help to derive the expected number of objects to be protected based on a setup of assumptions from the field. While this is a good estimate, “mileage” may vary. This document focuses on sizing for 1000 users.

2.1. Veeam Office 365 Data Sizing Assumptions

The following provides a list of assumptions for reference based on 1000 Users. 1000 users are assumed to have the number of objects tabulated below.

The following provides an assumed per user and total space consumption for Office 365 users.

This provides a reference point to extrapolate sizing for any number of users to protect. 1000 users will typically generate about 2,590 objects and utilize about 5TB of storage space.

2.2. Azure Architecture Compute Requirements

2.2.1. VBO365 Management Compute Requirements

The minimum compute requirements for the VBO365 server is 4 Cores / 8GB RAM and can manage up to 10 proxies and up to 160,000 objects.

While it is recommended to have standalone proxies, to save on cost in Azure, this 1st server can be a consolidated VBO365 Management Server + Proxy architecture, initially backing up 2,000 objects at minimum spec (4 Cores / 8GB RAM), which maps to an F4s v2 Azure VM size. This server can be scaled up to a D16s v3 to manage up to 9 additional proxies (a total of 10 proxies including itself) and backup 160,000 objects after scaling out with the 9 additional proxies.

On its own, the combined VBO365 + Proxy server can backup 16,000 objects which equates to about 6,000 users at maximum spec (16 Cores / 64GB RAM) based on assumptions in Section 2.1.

2.2.2. VBO365 Proxy Compute Requirements

VBO365 Proxies are the data movers, reading data from Office 365 and writing data to the backup repository. One standalone Proxy can handle about 16,000 objects. As the number of users grow, compute requirements steer more toward memory consumption. The minimum requirements for a proxy server is 4 Cores / 8 GB RAM to initially backup 2,000 objects and would scale up to 8 Cores / 32 GB RAM to process up to 16,000 objects.

Note: When scaling up the Proxy server compute resources, the VBO services should be restarted to become aware of the available new compute resources. This provides more efficient memory allocation.

Note: Additional proxies beyond the initial VBO365 server will require the VBO and Proxy instances to be domain joined. Azure Active Directory can be leveraged to accomplish this.

2.2.3. Suggested Azure VM Sizes

The following table provides suggested Azure VM sizes that can be utilized.

2.2.4. User to Server Architecture Translation Table with VM Sizes

Based on the previously stated object assumptions, the following table was derived to provide a translation of the number of users to objects, and finally to Azure VMs. Utilize this table to determine the Azure compute architecture needed. The table demonstrates how to scale up and scale out. It consists of the VBO365 server and a number Proxy servers. Of course “mileage” may vary but this provides a reference point.

2.3. VBO365 Repositories

For VBO365, unlike Veeam Backup and Replication (VBR), backup data is stored in a database file unless leveraging object storage. VBO365 repositories are a collection of database files in folder paths that can map to folders in an object storage bucket/container. An independent repository server is not required to host each repository. Instead, repositories are hosted by Proxy servers. A repository cannot be shared/accessed by more than one Proxy server.

Also, unlike VBR, retention policies are defined at the repository level rather than the job level. Therefore, for this reason alone each tenant should have their own repository depending on their retention requirements. If a tenant requires more than one retention policy, then a repository needs to be created for each retention policy a tenant has. Therefore, a tenant can have multiple retention policies, thus multiple repositories.

A defined repository for each tenant is also the mechanism in which multi-tenancy is achieved at the volume level. Tenant data is segregated into its own backup database file in its own folder on the volume.

Repository sizing depends on the storage consumed within Office 365. Assumptions can be made, or reports can be generated in Office 365 to provide metrics. From Section 2.1, field data suggest that a user typically utilizes an assumed 5 GB of storage in Microsoft Office 365. Thus, the required backup space can be computed.

There are 2 types of retention, Item-Level Retention and Snapshot-Based Retention. Snap based retention would require more storage space. Refer to the following link to learn more: https://helpcenter.veeam.com/docs/vbo365/guide/retention_policy.html?ver=40.

Note: The sizing in this document assumes snapshot based backups.

The following sections provides use case scenarios to help provide sizing guidance. This document focuses on building repositories that leverage object storage, specifically Azure Blob.

Note: The use of object storage is highly recommended for best reliability and scalability!

2.3.1. Block Storage Requirements (Metadata) and Object Storage (Backup Data)

In Azure it is recommended to leverage Managed Disks to serve as the repository space for all data. Furthermore, it is highly recommended to leverage Object Storage for the Backup data. Use of Object storage means that backup data will no longer be stored in the backup (database) file.

The block storage (direct attached to the VBO365 or proxy server) serves as storage space for metadata only (stored in the backup database file) while the backup data resides in the object storage. This minimizes block storage consumption to save on cost, but also provides greater data reduction in comparison to block storage.

The expected sizing for the metadata volume is about 1-1.5% of the Office 365 data. Additionally, backup data offers a 40-55% compression. The following table provides the estimated storage space required for the metadata volume based on Section 2.1 assumptions, as well as the Microsoft Disk sizes.

2.3.2. Virtual Network Service Endpoints

Virtual Network (VNet) Service Endpoints provide secure and direct connectivity to Azure services via an optimized route over the Azure backbone network. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Service Endpoints enable private IP addresses in the VNet to reach the endpoint of an Azure service without needing a public IP address on the VNet and can essentially avoid egress costs by preventing traffic from leaving the VNet.

Refer to the following link for more information: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview.