Object Storage
When utilizing an object storage repository, there are some special considerations regarding sizing.
Additionally, please read about Teams data.
Local Cache
As a rule of thumb, provide approximately 1% of the source data size as a local cache for metadata in the object storage repository, with a maximum of 100GB. This local cache, residing on local disks on the Proxy server, enables the avoidance of approximately 90% of the otherwise required API calls to the object storage during restores. Particularly in public cloud deployments, API calls to object storage are time-sensitive (considering latency for the round trip) and may incur costs.
Depending on the structure and type of data, the local cache size can vary between 1% to 3% of the source data within small environments but should never exceed 100GB. The local cache is a database, so it’s advisable to place it on SSD for optimal performance.
Object Storage Data Size
Because Veeam Backup for Microsoft 365 compresses the source data before storing it in object storage, the required space in object storage will generally be less than that of the source data.
Compression depends heavily on the type and structure of the source data and can vary. Keep in mind that most file formats, such as Microsoft Office files or pictures, are nowadays compressed by default within the file format. As a result, the space savings achieved by compression during backup can vary and depend on the data types.
| Item | Exchange Data | SharePoint |
|---|---|---|
| Average efficiency achieved by compression (up to) | 40% - 50% | 10% - 30% |
Object Sizes
Veeam Backup for Microsoft 365 does store data items in chunks within the object storage repository. Before compression, these chunks are 5MB for Exchange data and 8MB for SharePoint and OneDrive data in primary backup jobs. For backup copy jobs, these chunks are 256MB before compression, applicable to Exchange, SharePoint, Teams, and OneDrive data.
In addition, Veeam Backup for Microsoft 365 stores metadata in its own objects. These objects are small in size (100KB or less) and can constitute up to 50% of the overall number of objects in an object storage repository.
API Call Cost Estimation
Some Hyperscale Cloud Providers include API call charges as part of their object storage costs. Below, you’ll find information to calculate actual costs, though field observations suggest that API costs are generally only a fraction of the total storage costs.
In general, API call costs tend to be around 20% of storage costs during the first month, particularly when running the initial full backup. After this initial run, API costs often drop below 1 or 2% of the total storage costs. Due to this trend, we recommend disregarding API costs during the initial Total Cost of Ownership (TCO) calculation. Initial TCO estimates inherently involve a higher level of uncertainty related to data growth and usage.
Most object storage APIs are charged per 10,000 calls, and costs vary based on the type of call (write/read/list) and storage type (hot/cold). Be aware of the cost structure of your selected provider, as significant variations exist between providers and storage types.
It’s essential to note that this data can vary based on the type and structure of the source data and is intended to provide a broad idea of pricing.
To assist in calculating API call costs, refer to the following data from Veeam’s internal tests, running Veeam Backup for Microsoft 365 in Azure, backing up to Azure Blob storage, and performing backup copies to Azure Blob Archive.
Average Azure values per 100GB of source backup data
API Calls
The average number of requests per 100GB of source backup data when writing initial backup to Azure Blob.
| Backup Requests | Exchange Data | % | SharePoint Data* | % |
|---|---|---|---|---|
| PutBlob | 28,981 | 91.02% | 35,268 | 81.32% |
| GetBlob | 308 | 0.97% | 442 | 1.02% |
| ListBlobs/ListContainers | 11 | 0.03% | 216 | 0.50% |
| DeleteBlob | 2,527 | 7.94% | 7,156 | 16.50% |
| Other | 13 | 0.04% | 286 | 0.66% |
| Total | 32,158 | 100% | 43,802 | 100% |
*As Microsoft Teams and OneDrive rely on the SharePoint back-end, the SharePoint values apply also for Teams and OneDrive data
The average number of requests per 100GB of source backup data when writing backup copy to Azure Blob Archive.
Backup copy of Exchange Data
| Backup Requests | Source Blob | % | Target Archive | % |
|---|---|---|---|---|
| PutBlob | 191 | 0.39% | 1,200 | 28.90% |
| GetBlob | 48,700 | 98.37% | 268 | 6.45% |
| GetBlobProperties | 0 | 0% | 1,750 | 42.15% |
| ListBlobs/ListContainers | 0 | 0% | 269 | 6.84% |
| DeleteBlob | 53 | 0.11% | 557 | 13,42% |
| Other | 564 | 1.14% | 108 | 2.60% |
| Total | 49,508 | 100% | 4,152 | 100% |
Backup copy of SharePoint Data
| Backup Requests | Source Blob | % | Target Archive | % |
|---|---|---|---|---|
| PutBlob | 6 | 0.01% | 1,490 | 15.53% |
| PutBlock | 65 | 0.15% | 1,200 | 12,50% |
| GetBlob | 43,660 | 98.30% | 1,170 | 12,19% |
| GetBlobProperties | 0 | 0% | 2,850 | 27,70% |
| ListBlobs/ListContainers | 0 | 0% | 1,360 | 14,17% |
| DeleteBlob | 0 | 0% | 903 | 9,41% |
| Other | 682 | 1.54% | 624 | 6,50% |
| Total | 44,413 | 100% | 9,597 | 100% |
Synchronization
Synchronizing repositories becomes necessary when there is a disparity between the local cache and object storage metadata information.”
API Calls
The average number of requests per 100GB of source backup data.
| Synchronization Requests | Exchange Data | % | SharePoint Data* | % |
|---|---|---|---|---|
| PutBlob | 1,942 | 34% | 2,598 | 33% |
| GetBlob | 455 | 8% | 582 | 7% |
| ListBlobs/ListContainers | 2,929 | 51% | 4,094 | 51% |
| Other | 432 | 7% | 701 | 9% |
| Total | 5,758 | 100% | 7,975 | 100% |
*As Microsoft Teams and OneDrive rely on the SharePoint back-end, the SharePoint values apply also for Teams and OneDrive data
Restores
The available numbers for restores are less detailed but can give you an indication.
| Restore | Exchange | SharePoint |
|---|---|---|
| Data | 10.6 GB 70,061 items | 10.1 GB 529 items |
| Egress | 4.8 GiB | 4.7 GiB |
| Transactions | 3,700 | 2,840 |