Repositories are tightly coupled with proxy servers. While a single proxy server can host multiple repositories, each repository is uniquely coupled with a single proxy server.
Repositories can either be Object Storage or Microsoft Jet database (
.adb) based. In the latter case this can be on Direct Attached Storage (DAS), Storage Area Network (SAN) volumes or on a SMB3 Network Attached Storage (NAS) share.
INFORMATION Click on the best practices title to view more details on each topic.
Use Object Storage Repositories whenever possible - either on-prem or cloud
Object storage is more future proof. Today it already supports encryption and compression of objects, thus being more secure and space efficient than local Jet databases. Also it scales much better than local Jet databases on the file system and such avoids performance issues.
General security best practices apply - create an own storage user with own credentials for the bucket/container, apply restrictive ACL
Refer to the object storage provider and check security best practices for proper setup of containers/buckets.
Do not setup tiering policies on the object storage side. This is not supported and will break things.
Many object storage providers provide the possibility to configure tiering policies to move older objects from a high-cost/low-latency object storage to a low-cost/high-latency object storage, e.g. Amazon Glacier or Microsoft Cool Blob.
There is currently no built-in support in Veeam Backup for Microsoft 365 for these kind of archive tiers and the native tiering policies must not be configured because
- The archive tiers do use other APIs than the “normal” object storage. Data which is moved is not accessible anymore for VB365.
- Even old objects can still be part of the latest restore point. Think about a one year old email which is still in your inbox because it contains evergreen information. By tiering items older than a year to an archive tier, this mail would be inaccessible for Veeam while it is still expected to be part of yesterday’s backup when a restore kicks in.
Do not manually delete anything from the object storage bucket/container, unless you don’t want to use the repository anymore (then you can delete everything)
Interfering with the Veeam managed retention of objects in the repository can break the consistency of backups and thus must be avoided.
Provide disk space for ~1% of your source data size as local cache.
In case of restores this local cached metadata reduces the need of 90% of the required API calls to the object storage (which might incurr cost on public cloud) Read more detailled information in the sizing section for Object Storage
Use high throughput low latency storage. Thus DAS or SAN are preferred storage volumes for repository. Go with the default controller and stripe size settings.
Veeam Backup for Microsoft 365 (VB365) stores backup data in a Microsoft Jet database
.adbfile in the repository. As this means random I/O on the used storage a high IOPS and bandwidth storage is preferred. In general DAS or FC-SAN block storage is preferred over ISCSI or SMB based storage.
Repository File System should be chosen as NTFS.
Both NTFS and ReFS file systems are supported. When using ReFS, the data integrity features should be disabled in particular for volumes where data folders are located or at least exclude VB365 repository files. Integrity Streams can have a negative impact on the performance because of the read-modify-write process and additional fragmentation of the data files. For these reasons NTFS is recommended as it doesn’t require reconfiguration from the default settings for best results and thus is the simpler choice.
When formatting an NTFS volume which you want to grow later when you require more disk space, you have to choose the right NTFS cluster size in advance to meet the requirements for the maximum volume size. The NTFS default setting of
4kbwill only support volumes up to
16TB. The NTFS documentation lists the right cluster size to choose for which volume size.
Do not enable storage encryption, dedup or compression on the repository volume.
Dedup and compression are unsupported and storage encryption will add delay for each I/O, so for best performance it should not be enabled.
Separate repositories by data type (Exchange, OneDrive, SharePoint) to allow higher flexibility based on the different data-change characteristics
The maximum supported file size for the Jet DB database files (
.adb) is 64TB. An automatic rule triggers when the repository database files reaches 59 TB at which point a new repository database file is automatically created in the same storage location. This allows to overcome the first limit.
However, handling such large repositories (e.g. for migration purposes) comes with problems like long migration times, handling very large file systems, etc. Thus we recommend to limit the maximum size of target repositories by separating the backup data to different repositories. Especially separation by data type (Exchange, OneDrive, SharePoint) is reasonable, as depending on the type the change characteristics (amount of data, changerate) are normally different. While for Exchange a lot of objects might be changed, the amount of data is normally quite low, as most of it is just text. For OneDrive however, the average changed file size might be much higher because it is used to store large binary files. Even for the same type of data (e.g. OneDrive) it might be reasonable to again separate this data only, e.g. by business unit, when the overall data size is very high.
Avoid very large repositories because handling them gets harder. Distribute the backup data over several repositories, e.g. split by business units
Large repositories require large disks, which increase the size of the failure domain. Keeping repositories in a managable size is preferred. We see sizes of 200-300TB as managable sizes.
Keep 10% free working space per repository to avoid lock downs
Additional space for transaction protocols or database checkpoints is required per repository. There should always 10% free workspace per repository to compensate this.
Throttle the used bandwidth per proxy on a shared network connection to not block other applications
By default the proxy servers will take all available bandwidth to run the backups as fast as possible. As normally there is no dedicated internet connection available just for VB365 backup, it’s reasonable to throttle the maximum usable bandwidth (which is done per proxy) so that other applications do not suffer (too much). Depending on the backup schedule the limit should be set to a reasonable value. It might be okay to take 90% of the bandwidth at night but if the backup runs during working hours only 40% can be consumed without affecting operations.
- Veeam HelpCenter - Veeam Backup for Microsoft 365 User Guide
- Microsoft NTFS Documentation