Introduction
This blog series will cover deploying Veeam Backup for Microsoft 365, specifically an advanced deployment. Most are already aware that Veeam is the #1 backup software for Microsoft 365, protecting more users than many other vendors combined! One of the great things about VB365, is that it can be as simple as a single server, or be scaled out to handle more than 100,000 users.
In the upcoming posts, we will cover the installation and configuration of each of the components in the advanced deployment.
Let’s start with what a simple deployment looks like, and what an advanced deployment can look like:
Simple Deployment
Advanced Deployment
Components
There are several components that make up VB365, and in a scale out architecture, we will have most roles separated out and on dedicated machines. All these components communicate securely between each other, and ensure performance and reliability for the Microsoft 365 backups.
Backup Server
The Veeam Backup for Microsoft 365 server is the “control pane” for the entire deployment. This server will act as the management server, and is where everything is configured. The server console is here, as well as remote consoles installed on workstations connect back here, all secured behind credentials with multi-factor authentication (MFA). This is where the backup administrator will configure the environment including deploying the proxy pools and repositories.
Postgres Server
Version 8 transitions to using postgresql for the configuration database, as well as the metadata cache database for object storage repositories. This enables performance and reliability, as well as allows multiple proxies to write to the cache when sharing a single object storage repository. VB365 requires postgres 15.8 or higher.
NATS Server
Another addition in version 8 is NATS. No, not network address translation! NATS is a messaging or data exchange ‘middleware’ service that’s used by many different software packages in enterprises. In our case, it’s used to schedule items from running backup jobs onto the various proxy servers in the environment. Because of the nature of NATS, and specifically Jetstream, if a proxy goes offline during a backup job, the M365 items being processed are automatically assigned to the surviving proxies in the pool.
Proxy Pool
The Proxy servers are the data movers. These are what connect out the Microsoft 365 and download the data, compress it, convert it to objects, and send out the the repository. A single proxy server can be deployed, or multiple can be combined into a Pool, allowing them to work dynamically with objects from a job and targeting the same or multiple backup repositories.
Backup Repositories
The Backup Repository is fairly straightforward. These are either local storage, or the preferred object storage. Object storage repositories offer better performance and compressions compared to a local repository, and are the only repository type supported for a Proxy Pool. In Veeam Backup for Microsoft 365, the retention is set at the repository level – not at the backup job. Object storage repositories can be used for primary copies of data as well as for copy jobs; and both of those support native object lock immutability in both governance and compliance modes to ensure the data is unchangeable.
Restore Portal
This server hosts a web-based portal for restoring data back to Microsoft 365. While the Explorers still exist, and can be used by a backup administrator for advanced restores, including export, the Restore Portal exists to facilitate tole based access to group or individuals, allowing them to restore particular users or groups; only back to M365. This portal also acts as a self-service portal, which can allow end users to restore data from their mailbox or OneDrive.
What’s Next?
In the next post, we will start by deploying an Ubuntu server and installing and configuring Postgres for the config and cache databases to reside on, including a performance script to run after the VB365 server is deployed.
