This section covers the supported VB365 configuration maximums. Numbers might vary depending on deployments types and available resources. These values represent what’s currently supported also in light of acceptable performance. The values provided refer to any combination of Online and On-Premises environments that use Microsoft Exchange, Microsoft SharePoint, OneDrive for Business and Microsoft Teams.
The tables in this section use the number of objects and their variations as a metric for estimations.
- Mail (Primary, Archive, Shared, PublicFolder)
- Sites (SharePoint incl. Subsites, Personal, Teams)
- OneDrive for Business
These maximums are based on Veeam QA testing and the recommended maximums for the specified config.
|Type||Recommended Proxy Config (8C/32GB)||Minimum Proxy Config (4C/8G)|
|Proxies per VB365 controller||50||10|
|Objects per proxy1(Refer)||20,000||2,000|
|Objects per VB365 installation1(Refer)||1,000,000||20,000|
|Objects per organization1(Refer)||400,000||20,000|
|Users per job||5,000||500|
|Users per proxy2(Only)||5,000||500|
|Users per VB365 installation||250,000||2,500|
|Users per organization||100,000||2,500|
|Size per VB365 repositoryF3(The)||Unlimited||Unlimited|
The maximums per component (proxy, repo, installation, organization) must be maintained at the same time (e.g. number per objects and number per users).
|Default JET database instance memory consumption on Veeam Backup for Microsoft 365 repository||0.1% of host memory|
|Default JET database engine memory cache||50% of host memory|
|Recommended maximum number of JET databases per backup proxy||250|
|Max number of JET databases per backup proxy||750|
Do not forget to have enough memory available for the VB365 server operation when running a lot of databases. This will require a minimum of 15% of the hosts memory not allocated to other processes.
Only valid if each user uses all services (Exchange, Archive, OneDrive, Personal SharePoint site). Otherwise refer to objects per proxy recommendation. ↩
The local VB365 repo consists of multiple folders 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 maximum size per .adb file is 64 TB. To counter that limit an automatic rule triggers the generation of a new repo file in the same storage location when reaching 59 TB. For example, three-year retention creates three folders with one or multiple .adb files in it which each can grow up to ~60TB. ↩