Veeam Backup for Microsoft 365 v8: Architecture, Setup, and the Explorers

Microsoft's position on your 365 data is the same as Salesforce's: they keep the service running, you keep the data safe. Deleted items come back from the recycle bin for 93 days if you are lucky. After that, they are gone. Retention policies are not backup. They were designed for compliance, not recovery. Veeam Backup for Microsoft 365 v8 is the current answer to this problem, and v8 is a significant architectural shift from v7. This article covers what changed in v8, how to deploy it, how to configure jobs for all four workloads, and how the Explorers work when you actually need to recover something.

---

What Microsoft Does Not Cover

Exchange Online retention policies keep deleted items in a recoverable state temporarily. SharePoint and OneDrive versioning helps with accidental overwrites if someone catches the problem fast enough. Teams messages deleted by a user are gone from the Teams UI even if technically present in Exchange for a period. None of this is backup in any meaningful sense. There is no point-in-time restore, no cross-tenant recovery, no granular item search across a historical timeline. Those gaps are exactly what Veeam fills.

---

What Changed in v8

v8 is not a minor update. The architecture changed at the database and proxy layers in ways that affect how you deploy and scale the product. If you are running v7, you need to understand what you are upgrading into before touching the upgrade button.

SQLite to PostgreSQL NEW

v7 and earlier used SQLite for the configuration and per-proxy cache databases. v8 replaces all of that with a centralized PostgreSQL instance. This is not cosmetic. PostgreSQL unlocks multi-proxy shared cache, which is a prerequisite for proxy pools. It also improves performance and reliability at scale. In previous versions the persistent repository cache lived on each proxy server individually. In v8 it lives in PostgreSQL, which means multiple proxies can read and write the same cache for the same object storage repository. PostgreSQL 15.8 or higher is required.

Proxy Pools NEW

In v7, you could have multiple proxy servers but they operated independently. In v8, you can group proxies into a proxy pool, which functions as a single logical unit for backup, backup copy, and restore operations. The pool distributes jobs across all available proxies, balances load, and stays under the radar of Microsoft's throttling by spreading API requests across the pool. Object storage is the only repository type supported for proxy pools. If you need to scale beyond a single proxy, this is how you do it in v8. The Veeam best practice guide recommends no more than 20,000 protected objects per proxy server configured with 8 cores and 32 GB RAM. Scale your proxy count against your total object count.

Linux Proxy Support NEW

v8 added Linux proxy support - RHEL and Ubuntu initially, with RHEL 9.6 and Windows Server 2025 support added in v8.2. This reduces TCO for large scale-out deployments and gives you more placement flexibility. Linux proxies can be standalone or as pool members.

NATS Server NEW

The NATS server is a new infrastructure component that handles communication between proxy servers in a pool. It uses JetStream technology for message queuing and streaming between backup infrastructure components. You install NATS as part of the VBO365 deployment, either on the same host or on a dedicated one. The same NATS server cannot be shared across separate VBO365 deployments.

Immutability NEW

v8 delivers full immutability on primary object storage repositories. Supported platforms are Amazon S3 (S3-compatible, governance and compliance modes), Azure Blob Storage, IBM Cloud Object Storage, and Wasabi. Both primary backups and backup copies can be made immutable, which closes the air gap for ransomware scenarios where the backup environment itself is targeted.

MFA and RBAC NEW

v8 added MFA to the console and Explorers. It also introduced proper RBAC with a Users and Groups section where you define who has backup administrator access. Previously, access control was more coarse-grained. For organizations that need to scope access per MSP tenant or per business unit, this matters.

Teams Private and Shared Channels NEW

v8 shipped with full coverage for private and shared Teams channels, not just standard channels. Earlier versions covered standard channels only. If your organization uses private channels for sensitive projects or shared channels for cross-org collaboration, this was the gap v8 closed at GA.

---

Architecture

v8 has more moving parts than v7. Map your deployment before installing anything.

Veeam recommends deploying the VBO365 server, PostgreSQL, and NATS server on separate machines for production. For smaller environments - a few hundred users, a single proxy - the all-in-one deployment on one Windows server works fine. Scale out as you grow.

---

System Requirements

---

Deployment and Initial Setup

Download the installer from the Veeam downloads page. Run it on your designated VBO365 server. The installer wizard handles the component selection, license file input, and the PostgreSQL and NATS connection prompts.

1. 1Pre-install: prepare PostgreSQL. Either install a new PostgreSQL 15.8+ instance or prepare an existing one. If new, Veeam can install PostgreSQL 15.14 locally during setup. If using an existing instance, ensure it accepts remote connections, has the required extensions, and uses UTF-8 encoding. Configure PgBouncer if your environment will exceed 1,000 repositories or has high proxy counts. See KB4758 for the PgBouncer configuration guide.
2. 2Run the VBO365 installer. Select the Veeam Backup for Microsoft 365 component. Accept the license agreement, provide your license file, and let the system configuration check run. Review the default installation settings and adjust the install path if needed.
3. 3Configure PostgreSQL connection. Point the installer at your PostgreSQL instance. If installing PostgreSQL locally, the installer handles this automatically. For remote instances, provide the host, port, credentials, and database name.
4. 4Configure NATS. The installer deploys or connects to a NATS server. For simple single-proxy deployments, NATS on the local machine is fine. For proxy pools, deploy NATS on a dedicated host first and point the installer at it.
5. 5Complete the installer. After installation, open the Veeam Backup for Microsoft 365 console. You are now ready to add your Microsoft 365 organization.

Adding a Microsoft 365 Organization

1. 1In the console, open the Organizations view. On the Home tab, click Add Org on the ribbon, or right-click the Organizations node and select Add organization. Select Microsoft 365.
2. 2Select Modern authentication (app-only). Legacy authentication is deprecated. Create or register a Microsoft Entra application with the required permissions documented in the Veeam Help Center under Microsoft Entra Application Permissions. The required Graph API scopes differ per workload: Exchange, SharePoint/OneDrive, and Teams each have their own permission requirements.
3. 3Provide the application ID, tenant ID, and certificate or client secret from your Entra app registration. Authorize the connection. Veeam will verify the connection and enumerate the organization's data.

---

Adding Proxies and Repositories

The default local proxy is sufficient to start. Add remote proxies as you scale, then add repositories. For proxy pools, all repositories must be object storage.

1. 1In the console, navigate to Backup Infrastructure. Under Backup Proxies, click Add. Provide the server hostname, OS type (Windows or Linux), and credentials. VBO365 deploys the proxy service.
2. 2To create a proxy pool, select multiple proxy servers, right-click, and choose Add to Pool. Name the pool. Jobs that target the pool distribute across all member proxies automatically.
3. 3Under Backup Repositories, click Add. Select object storage (preferred) or local storage. For object storage, provide the bucket details, access credentials, and optionally enable immutability. Set the retention policy at the repository level.

---

Creating Backup Jobs

Jobs define what to protect and where to write it. One job can cover an entire organization or a granular selection of users, groups, sites, or teams. Veeam recommends no more than 2,000 users per job for optimal performance in large environments.

1. 1In the Organizations view, right-click the organization and select Add to Backup Job, or click Backup in the ribbon and choose New Backup Job.
2. 2Scope: Choose whether to protect the entire organization, or specific users, groups, sites, or teams. You can mix selections - for example, protect all users but explicitly exclude a service account, or protect specific SharePoint sites without touching Exchange.
3. 3Objects: For each user or group in scope, select which data types to include: Mail, Archive Mailbox, OneDrive, Calendar, Contacts. For sites: SharePoint data. For Teams: standard, private, and shared channels.
4. 4Proxy and repository: Select the proxy or proxy pool and the target repository. If you select a pool, VBO365 distributes the job across pool members automatically.
5. 5Schedule: Set the backup frequency. The minimum RPO VBO365 supports is 5 minutes. For most environments, hourly is practical. You can configure separate RPOs for different object types within the same deployment.
6. 6Finish and enable the job. The first run performs a full enumeration of the protected scope. Subsequent runs are incremental.

---

The Veeam Explorers: Restore Workflows

The Explorers are where you spend your time during actual recovery events. Each workload has a dedicated Explorer designed for its data model. You access them all from the same entry point: right-click a backup job or organization in the console and select Explore. You can explore the latest state, a specific point-in-time state, or retrieved data from archive storage. You can also explore all organizations at once if you need to search across tenants.

---

Restore Portal

The Restore Portal is a separate web-based interface that allows non-admin users to perform self-service recovery of their own data. A user logs in, selects their mailbox or OneDrive or SharePoint site, picks a restore point, and recovers what they need without ever involving IT for individual item recovery. Restore operators can be scoped to specific users or groups, so you can delegate recovery for a department without granting full backup administrator access. The portal covers Exchange, SharePoint, OneDrive, and Teams.

---

Gotchas and Common Failure Modes

• !PostgreSQL shared with VBR fails the installer. The most common v8 first-deployment problem. VBR's PostgreSQL instance is configured for local connections only. VBO365 needs remote connections. They cannot share the same instance without manual PostgreSQL reconfiguration. See KB4638.
• !Proxy upgrades after VBO365 server upgrade. After upgrading the VBO365 server, you must upgrade all proxy servers. This is easy to miss. Proxies on an older version than the server will have connection issues or fail to process jobs.
• !PostgreSQL default config is not production-ready. The default PostgreSQL configuration that ships with the installer is sized for minimum resource consumption. For any serious environment, adjust the PostgreSQL config per the best practices guide. Use a dedicated SSD-backed host for PostgreSQL at scale.
• !One NATS server per VBO365 deployment. You cannot share a NATS server across multiple VBO365 deployments. If you have separate VBO365 instances (for example, separate MSP tenants), each needs its own NATS server.
• !Proxy pools require object storage repositories. Jet-based (local) repositories are not supported for proxy pool members. If you want to use a proxy pool, your target repositories must be object storage.
• !Teams messages cannot be restored back to Teams - full stop. The official docs are explicit: Microsoft Teams messages cannot be restored directly back to Teams. There is no workaround, no hidden setting. Files restore fine. Structure restores fine. Message history does not go back into the channel timeline. Export as .msg files. Set expectations before someone promises it to a business owner.
• !Archive mailbox failures after upgrading. A known issue in v8.1 and v8.2 affects archive mailbox processing. If a backup job fails with "Mailbox is not fully configured" for archive mailboxes, check the current build number against the KB notes for the version you are running and update proxies accordingly.
• !Legacy authentication is gone. v8 removed support for basic authentication and legacy protocols. If you are running any authentication configuration that depends on legacy auth, it will fail after upgrade. Ensure your Entra app registration uses modern app-only authentication before upgrading from v7.
• !Exchange.ManageAsApp and Global Reader required after upgrade. After upgrading to v8, you must grant the Exchange.ManageAsApp permission and the Global Reader role to the Microsoft Entra application. Without both, public folder and discovery search mailboxes are silently skipped from processing and shared mailboxes are misidentified as user mailboxes. This is the single most common post-upgrade issue on the forums. Edit your organization in the console, select Use an existing Azure AD Application, check the Grant permissions checkbox, and finish the wizard. Or grant both manually in the Entra admin center.
• !Microsoft throttling enforcement on multiple backup app registrations (KB4821). As of March 1, 2026, Microsoft enforces its terms of use prohibiting multiple application registrations performing the same operations within a tenant. Previously, deploying multiple backup application registrations was a common workaround to spread API requests and reduce throttling. Microsoft now pools throttling limits across all similar applications in a tenant, so extra registrations no longer help and violate the terms of use. If your environment uses additional backup applications (right-click your organization, Manage backup applications), remove them. They no longer improve performance. This affects all third-party backup vendors, not just Veeam. See Veeam KB4821 for the full support statement.
• !Upgrade from v7 migrates all databases to PostgreSQL. The v7 to v8 upgrade is not trivial. All SQLite config and persistent cache databases from local and remote proxies are migrated to the centralized PostgreSQL instance. A 50 GB configuration database takes up to 15 minutes. Plan your maintenance window based on your database size, not just the installer runtime.

---