Quotas & Limits: Retention & Policy Constraints
The concrete numbers and constraints behind retention and archiving configuration.
Two separate settings named similarly
BYOVault has two distinct, independently configured numbers that both get called “retention,” and the table below is organized around keeping them apart.
- The per-workload archiving threshold (one value per workload: SharePoint, OneDrive, Exchange, file server) controls when a file moves into the vault in the first place, anchored to the file’s own real last-modified date.
- The vault’s locked retention period is the number actually sent to Azure or AWS and is what keeps a file undeletable once it has arrived.
See Archiving and Retention Policy for the full explanation of each; this page only lists the hard constraints.
| Rule | Value | Enforced where |
|---|---|---|
| Per-workload archiving threshold — starting suggestion shown in the wizard | 180 days | Wizard default; can be changed before or after saving |
| Per-workload archiving threshold — minimum allowed value | 1 day | Rejected at save time if lower |
| Vault lock retention period — must be positive | > 0 days | Rejected at provisioning time if zero or negative |
| Locked vault’s retention period can only increase | New value must be strictly greater than the current value | Enforced independently at multiple layers, so it holds even if one layer were ever bypassed |
| Azure lifetime retention-extension cap | 5 increases per locked container | Enforced by Azure itself; BYOVault tracks the count and blocks the 6th attempt before it reaches Azure |
| All backup schedules on one tenant must share one retention value | Every schedule for a tenant must use the same retention length | Rejected at save time if a schedule’s value would differ from the others |
Per-workload archiving threshold: default and minimum
Each workload (SharePoint, OneDrive, Exchange, file server) has its own archiving threshold, so each can archive on its own schedule of staleness rather than sharing a single tenant-wide number.
The 180-day figure is not a silently enforced default — it is only what you see pre-filled in the wizard the first time you configure a tenant, and it can be changed before or after saving.
The only hard floor is that a submitted threshold must be at least 1 day; anything less is rejected with an explicit error.
Because the threshold is set independently per workload, one tenant can freely run a shorter threshold for a fast-changing workload and a longer one for a comparatively static one — there is no requirement that every workload share one number, unlike the vault’s own retention period described below.
A threshold set too low for a workload with frequently-edited files will archive content that is still being actively worked on.
This does not lose data: restoring an archived file works exactly the same as restoring one that has not yet been archived.
Vault retention period: positive, and increase-only once locked
The vault retention period is the number actually passed to Azure’s immutability policy or AWS Object Lock’s default retention when a vault is provisioned.
Provisioning rejects a value that is zero or negative outright, since locking a vault without a real retention period would leave nothing for the cloud provider to enforce.
Once a vault is locked, its retention period can only ever be increased, never decreased.
This guarantee is enforced independently at multiple layers, so it holds regardless of how the change is attempted — including a direct attempt to unlock a vault early. This is what makes the locked state a genuine guarantee rather than a convention.
Azure’s five-extension lifetime cap
A locked, container-level Azure immutability policy accepts a maximum of five extension calls over its entire life — a limit Azure enforces on the policy itself.
BYOVault keeps its own running count and refuses a sixth attempt with an explicit error rather than forwarding a call Azure would reject anyway.
AWS Object Lock has no equivalent cap; see Extending a Retention Period for the full behavioral difference between the two providers.
One retention value per tenant, across every backup schedule
All backup schedules for a tenant must share one retention value (default 90 days).
Before accepting a new or changed value, BYOVault checks every other schedule for the tenant and rejects the request if any of them holds a different value.
This check only applies once retention-vault archiving is enabled for the tenant in the first place — a tenant without archiving on has nothing for this value to act on.
This value drives a separate mechanism from the vault’s own locked retention period: on an ongoing basis, it marks an archived item as retention-locked once its time in the vault exceeds this many days. That elapsed time is measured from when the item was first backed up, not the file’s real source-side last-modified date.
Because this applies tenant-wide rather than per-schedule, two schedules on the same tenant disagreeing on retention length could cause one schedule’s data to be marked locked too early or too late relative to what its own operator configured — which is exactly what the shared-value rule exists to prevent. This step tracks locking state only; the actual immutability guarantee comes from the locked vault itself, as described above.
See Planning Your Retention Period for guidance on choosing values deliberately given that the vault’s own lock is irreversible in the downward direction.
See Backup Schedule Design for planning around the shared-retention-per-tenant constraint when splitting workloads across multiple schedules.