BYOVault documentation

BYOVault backs up Microsoft 365 (SharePoint, OneDrive, Exchange) and on-prem file servers directly into a cloud storage account you already own — Azure Blob or AWS S3. This section documents exactly what that means in practice: what's captured, how it's encrypted, how retention and restore actually work, and where the current limits are.

How it fits together

A tenant connects Microsoft 365 via a standard Entra OAuth consent grant, and points BYOVault at a storage destination it controls — an Azure Blob container or an S3 bucket.

From then on, BYOVault runs scheduled backup jobs that pull data from Microsoft Graph, encrypt it, and write it straight into that destination.

BYOVault’s infrastructure never holds a second copy of your data. It holds metadata only — what was backed up, when, and where in your bucket it lives — not the content itself.

Bring your own storage

This is the core architectural decision behind the product: encrypted backup data is written to your Azure or AWS storage account, not BYOVault’s. If you were to cancel BYOVault entirely, the data already written to your bucket stays exactly where it is.

What's covered here

Workloads

SharePoint, OneDrive, Exchange, and file servers — what's captured and what isn't.

Restore

Version history and in-place restore — and its real, per-file limits.

Retention & Archiving

How files move into a provider-locked vault, and stay protected there.

Security

Encryption, key management, and how storage credentials are held.

Self-Service Portal

What end users can restore themselves, and who has to approve it.

MSP & Multi-Tenancy

Managing multiple client tenants from one dashboard.

What this documentation won't do

It will not soften or omit unfavorable details. Where a limitation exists, it is stated plainly on the relevant page instead of left for you to discover during a live incident:

Where a workload is not backed up (Teams), that gap is called out on the relevant page.
Where a restore is not possible (bulk drive restore), that limit is called out as well.
Where a security property is narrower than it might sound — by default, per-tenant keys are derived from one shared master key, not customer-held keys — that distinction is documented too, unless a tenant enables BYOK with their own AWS KMS or Azure Key Vault key.

Readers new to BYOVault should start with the Quickstart, which walks through connecting a tenant, attaching storage, and running a first backup end to end.

NextHow BYOVault Works