Veeam Backup for Microsoft 365 Best Practices: Configuration, Sizing, and Optimization Guide

TL;DR:

• Plan sizing and architecture early. Identify objects, data volumes, and retention needs to design efficient repositories and proxy pools.
• Optimize infrastructure for performance. Use dedicated PostgreSQL servers, PgBouncer connection pooling, and NATS message broker for scalable, resilient backups.
• Follow best practices for large environments. Split jobs by service, use proxy pools, and schedule backups off‑peak to reduce throttling and bandwidth limits.
• Protect data with Veeam’s enterprise‑grade resilience. Apply configuration maximums and object storage best practices for fast, reliable recovery across Microsoft 365 services.

Why Microsoft 365 Backup Best Practices Matter

The evolution of Microsoft 365 and backup challenges since 2016

When the first version of Veeam Backup for Microsoft 365 was released in 2016, no one realized how fast Microsoft 365 would grow and how our daily communication and work life would change. New features and software were added to the Microsoft 365 package.

At that time, there were still various challenges. Object storage was not yet state of the art and there were not that many customers with larger user numbers in enterprise environments. We soon found out that we had created a successful product with a lot of potential, which was improved from version to version.

How Veeam Backup for Microsoft 365 has evolved through versions

Veeam Backup for Microsoft 365 v8.1 has been successfully released. Due to constant improvements and innovations in the product, the best practices have also changed.

You can find all current best practices in our official best-practice-guide: Best Practice Guide (Big Kudos to our Solution Architects and the Product Management to bring all the knowledge together).

In this article we would like to deliver a better point of view about the background of the best practices and provide a comprehensive understanding for successful and simple infrastructure planning.

If you want to avoid the complexities of setup and configuration, Veeam Data Cloud for Microsoft 365 offers a streamlined SaaS solution. It provides a ready-to-use backup environment with integrated storage and straightforward licensing, managed by Veeam.

Understanding Veeam Backup for Microsoft 365 Architecture

The strength of Veeam Backup for Microsoft 365 is its simplicity combined with our maximum flexibility. However, these advantages also make further planning difficult because there is not “the one” perfect solution.

Whether cloud-only, on-premises or a mix of both, Veeam will give you the ability to integrate perfectly with your infrastructure and strategy.

Key Components: Management Server, Proxy, Repository

For successful best practices and sizing, you need to take a closer look at your environment. You need the following data to draw further conclusions:

• Number of objects to be backed up per service (Mail, SharePoint/Sites, OneDrive, Teams).
• Data volume for each service to be backed up (Mail, SharePoint, OneDrive, Teams)
• Retention period of your backup data
• Repository type for your backup data (Disk-Repository or Object Storage Repository, see section “The repository”)

Data Points Needed for Accurate Sizing

For better understanding, these are the following recommendations within Veeam Backup for Microsoft 365 that serve as a basis for a successful sizing:

Current numbers:

An object is equal to one service of one user. A service is Mail, Archive, OneDrive, personal site, a SharePoint site or a Teams Objects, etc.

For example, if a user backs up all services, you are using four objects.

For more information please see:

Configuration Maximums

To build a suitable backup environment, it is necessary to understand our backup technology and strategy.

Infrastructure and Performance Requirements

The Management Server

The actual server is a pure administrative component and is used for connecting an organization in Microsoft 365, creating backup jobs and managing the infrastructure.

The management server is automatically installed together with the first proxy server during the initial installation. These services can be run together, as the management server requires only a few resources (RAM, CPU) in smaller environments. Since v8 we also recommend to not use the default proxy.

PostgreSQL Database Server: IOPS and Memory Guidelines

The default setup is installing a PostgreSQL Database service alongside with the Veeam Backup for Microsoft 365 Server services, but it might be required to deploy it in an advanced way for larger environments.

To adjust the PostgreSQL Instance configuration, please follow the Veeam Helpcenter instructions:

https://helpcenter.veeam.com/docs/vbo365/guide/adjust_postgres_instance.html

Compute requirements

Consider that the configuration and cache database are highly loaded and resource-consuming. For optimal performance, we recommend using an SSD drive with at least 5000 IOPS, better 7500IOPS (including installations on Azure and AWS instances). IOPS consumption varies according to the frequency of backups, the number of jobs, the size of protected Microsoft organizations, and so on. It is recommended to plan the compute resources according to the given scenario:

• Up to 60.000 objects: 4 CPUs and 8 GB RAM
• Above 60.000 objects: A dedicated PostgreSQL Database Server with 8 CPUs and 32 GB RAM

PgBouncer Connection Pooling for Scalability

PgBouncer is a lightweight connection pooler for PostgreSQL. Each proxy and repository must connect to the PostgreSQL database when using Veeam Backup for Microsoft 365. This can quickly create thousands of separate database connections in larger environments, overloading the PostgreSQL server’s resources and network, causing performance issues.

PgBouncer helps by pooling those connections

Please follow the instructions in the KB Articles:

KB4728: How to Install and Configure PgBouncer for Veeam Backup for Microsoft 365

KB4758: PostgreSQL and PgBouncer Sizing and Configuration Guide

NATS Server: Message Broker for Job Coordination

The NATS server is a message broker for proxies, proxy pools and controller. It builds processing queues and maintains operational streams for jobs, sessions and more. It can be running on a Linux or Windows host where we’ve a preference for a Linux installation.

Think of the following when deciding for a NATS solution:

• Use a single node for performance optimization.
• Use a 3-node cluster for redundancy and accept a possible performance reduction.

Proxy and Proxy Pools: Scaling Microsoft 365 Backup Performance

The proxy server is the main component that downloads all data from Microsoft and processes the backup data and stores it on a repository.

Proxy pools are introduced since v8 and offer a logical grouping of multiple Proxies. The focus is on horizontal scaling to distribute processing over multiple Proxies.

Proxy Pools only work with Object Storage used for Repositories and each Proxy Pool can be associated with multiple Repositories, but keep in mind that a Repository can only be coupled with one Proxy Pool or as single Proxy.

As a best practice it is advised to use Proxy Pools whenever possible, they provide the ability to operate in a more flexible backup infrastructure for scaling and maintenance.

Of course, the available bandwidth on the customers side also plays a major role, but there are limitations on Microsoft’s side as well.

What use are 10 proxy servers when they are each restricted by an inadequate Internet connection?

For example, if you are connected to a high-performance Internet line, it does not mean that your backup will be downloaded quickly. Usually we see the limitation in the bandwidth provided by Microsoft (source-side).

Proxy Pools:

One of the biggest challenges is the dependency on Microsoft. Factors beyond our control may negatively affect the performance of our backup, yet they are still essential for a successful one:

-The bandwidth (For more information see: Microsoft 365 network connectivity principles)

-The throttling:

How to temporarily turn of Microsoft M365 throttling

Veeam Best Practice Guide – Throttling

In addition, depending on the current load in the Microsoft 365 data center or access point, faster or slower access is granted. This cannot be influenced or increased.

Therefore, set the backup times preferably outside the normal working hours. At this time, the access points usually have a lower load and you will see a higher backup speed.

Repository Design: Disk vs Object Storage and Cache Optimization

The repository can be a local disk repository or an object storage.

For a high-performance backup and full support of all features, with a better scalability approach we recommend object storage.

Veeam Disk Repository – Best Practices

Veeam Object Storage Repository – Best Practices

If you a looking for a good estimation for your future requirements and costs you can use the Veeam Capacity Calculator.

The Cache

Cache helps reduce costs incurred by your cloud storage provider when writing or reading data to and from the object storage repository.

When you use Veeam Explorers to open backups located in an object storage repository, Veeam Backup for Microsoft 365 retrieves the structure of the backed-up objects from the cache instead of downloading data directly from the cloud. This allows you to browse and navigate through the backup structure in the inventory pane of Veeam Explorers without incurring additional read costs.

Cache contains metadata that holds information about backed-up objects. It is created or updated during each backup session and stored in the PersistentCache database, which is managed by Veeam Backup for Microsoft 365 on a PostgreSQL instance.

When we talk about sizing the average cache database size is around 10GB per repository, but analysis of larger productive installations in the field showed the cache database sizes can grow up to 50GB per repository. Please monitor the overall database growth and adjust disk space accordingly.

Optimizing for Large Microsoft 365 Environments

For large environments (over 2000 users) you can consider some optimizations when creating jobs.

Consolidate backup jobs with the same services on a proxy server or pools. Create separate repositories for each service and mount them individually in the backup infrastructure.

For enterprise environments it is essential to increase flexibility in job configuration to ensure future usability. It is advisable to split the services into individual repositories right from the start.

If you are currently migrating your environment or there are already plans for future growth. You can split up the jobs from scratch and separate them in future on dedicated proxies.

Please refer to the recommended configuration maximums for details on how many objects/users can be in one job. The best practice is to stay well below (50-75%) the recommended maximum to allow for job expansion when required while still staying within the limits.

This pre-sorting from the beginning of your configuration allows you to separate the corresponding backup data with the backup APIs on Microsoft’s side.

For a better understanding:

The backup/graph APIs are addressed by Veeam in parallel, so jobs can run simultaneously without provoking throttling.

Another advantage of the parallelization of the backup jobs is their dependency in case of an error within the data structure. For example, a backup job that backs up all services is processed step by step. If, however, a SharePoint share contains a corrupt file, this behavior affects the entire backup job.

To avoid unnecessary storage space consumption you can consolidate SharePoint and Teams jobs on one repository, due to the service infrastructure design of Teams.

Teams creates a SharePoint page for each channel and saves nearly 80% of its data on SharePoint.

Warning: If you split up SharePoint and Teams in separate repositories and jobs, data will be backed up and stored twice.

In the following example, we have three proxies/pools that are only responsible for certain services and use their own repository for each service.

Designing Backup Jobs in Veeam Backup for Microsoft 365

You can define all these dependencies (Backup Job -> Service -> Proxy -> Repo) in the backup job wizard.

To avoid that users are accidentally forgotten in larger environments it is advisable to work with backup groups based on Dynamic Azure Active Directory groups. (Job Design with Azure Active Directory Groups)

For SharePoint and Teams backup we need to consider that there are not only user objects. For SharePoint pages as well as for Teams we need to work with the related objects.

You can also use a script to simplify this process in enterprise environments:

SharePoint and Teams JobManager

For a better overview and documentation predefine all settings in a short list:

Ensuring Reliable and Scalable Microsoft 365 Backups with Veeam

Veeam Backup for Microsoft 365 delivers a proven, enterprise‑grade solution for safeguarding Microsoft 365 data. Success depends on understanding each component of the backup architecture, from management servers and proxy pools to repositories and job design.

By applying the sizing and configuration best practices outlined in this guide, organizations can optimize backup performance, maintain data integrity, and ensure fast, reliable recovery across Exchange Online, SharePoint, OneDrive, and Teams.

For tailored guidance or architectural planning, reach out to Veeam experts or authorized partners to design a solution that matches your organization’s scale, compliance needs, and growth strategy.