Microsoft 365 backup sizing starts from a different place than sizing for virtual machines. There are no disks to count and no hypervisor reporting provisioned space. The data sits in mailboxes, document libraries, personal drives and chat histories, each of which grows at its own pace and is retained under its own rules. A repository sized from the tenant's storage report alone tends to be too small within a year.
This post sets out the inputs that determine how much backup capacity a Microsoft 365 tenant needs, and how retention turns a modest first backup into a much larger steady state.
A Microsoft 365 backup usually covers four services. Exchange Online holds mailboxes, archives, calendars and shared mailboxes. SharePoint Online holds team sites and document libraries. OneDrive holds each user's personal files. Teams adds channel messages, files and settings, most of which are physically stored in SharePoint and Exchange behind the scenes. The backup product reads each service through Microsoft's interfaces and writes the result to a repository, which for most current products can be S3-compatible object storage.
| Input | Where to find it | Effect on backup size |
|---|---|---|
| Mailbox data, including archives | Exchange usage reports | Compresses moderately, changes daily in small amounts |
| SharePoint site storage | SharePoint admin center | Often the largest share, includes file versions |
| OneDrive storage | OneDrive usage reports | Varies widely per user, grows with sync habits |
| Version history settings | Library settings per site | Many versions of large files multiply stored data |
| Daily change rate | Measured over the first weeks of backup | Sets the size of each incremental |
| Retention period | Policy and regulation | Determines how many changes and deleted items are kept |
| Leavers and inactive accounts | HR and license records | Data kept in backup after the license is removed |
Mail is the most predictable component. Mailboxes grow steadily, change rates are small as a share of the total, and message data compresses reasonably well. The surprises come from archives and shared mailboxes, which are easy to leave out of an estimate, and from retention. If the organization keeps mail backups for seven years, every message deleted by a user during those years stays in the repository even though it has left the tenant.
SharePoint and OneDrive are harder to predict. Storage reports show the current size of each site, which includes version history, but they do not show how fast files turn over. A design team that saves large files many times a day generates far more backup data than an office of the same headcount working on text documents. Video recordings of meetings are another source of fast growth, since each recording is a large file that never changes and is rarely deleted.
The reliable way to size the file component is to measure it. A two to four week pilot backup shows the real daily change, and that figure can be projected over the retention period with more confidence than any per-user rule of thumb.
The first full backup of a tenant is roughly the size of its current data after compression. What follows depends on retention. Each day adds the changed and new items, and nothing leaves the repository until its retention expires. Over a one-year retention the repository typically grows well beyond the size of the live tenant, and over several years it can reach a multiple of it.
Two retention models are common. Item-level retention keeps each item for a set time after it was last modified or deleted. Snapshot-based retention keeps the tenant's state as of each backup for a set time. They produce different capacity curves, so the estimate should use the model the backup product will actually apply. The cost of another year of retention shows how to price an extension before agreeing to it.
Staff turnover adds data that the tenant report no longer shows. When an account is removed, its mailbox and OneDrive eventually disappear from Microsoft 365, but the backup keeps them for the retention period. In an organization with regular turnover, former users can account for a meaningful share of the repository.
Growth needs its own allowance. Headcount, adoption of Teams and the steady increase in file sizes all push the total upward. Sizing for growth and churn covers how to add a forward buffer on top of a first-pass figure.
A simple model has four lines. The first is current data per service, taken from the usage reports. The second is the measured daily change per service, multiplied by the number of days in the retention period. The third is an allowance for leavers, based on annual turnover and average data per user. The fourth is annual growth applied over the planning horizon, usually three years. Compression is applied to the total using the ratio observed in the pilot, not a vendor's best case. Backup repository sizing gives the general method this follows.
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Backup products that protect Microsoft 365 and write to S3-compatible storage can use it as their repository, alongside virtual machine and file backups in separate buckets. Immutability is provided by S3 Object Lock on each object where the backup product supports it.
Because Microsoft 365 repositories grow steadily with retention, it helps that ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB. It is used as a target for Veeam and other backup software.
A Microsoft 365 sizing is worth checking after three months of real backups. By then the actual change rate, compression ratio and retention behaviour are visible in the repository's own statistics, and the three-year projection can be corrected while there is still time to plan capacity calmly.