"Your bucket, your keys": what that actually means for Microsoft 365 backup

Most Microsoft 365 backup products are a black box: your Exchange, OneDrive, and SharePoint data goes into the vendor's storage, under the vendor's retention policy, and comes back out only through the vendor's restore tool. That is a reasonable trade for a lot of buyers — until the day you want to switch vendors, negotiate a renewal, or just know exactly where a copy of your client's mailbox physically lives.

Nexus backs up Exchange Online, OneDrive, and SharePoint through the Microsoft Graph API the same way other tools do — the difference is where the data lands. It writes to an S3-compatible bucket you own: Wasabi, AWS S3, or Cloudflare R2, configured with your own credentials, which we store encrypted and never see in plaintext.

What "your bucket" changes in practice

• You can point a second tool at the same bucket, or move providers, without a migration project — the data was never siloed inside our storage to begin with.
• Retention is your policy, on your bucket, not a vendor default you have to trust.
• If we ever had an outage or a dispute, your backed-up data does not become a hostage to it — it is already sitting in infrastructure you control.

A backup you cannot get to without the vendor is a beautifully-presented single point of failure.

The other half of "trust but verify" for backup is proving a backup actually restores, not just that a job reported success. Every object we write is hashed and verify-checked with a rehash pass, so "backed up" means the bytes are provably intact, not just that an API call returned 200. Restore is per-item — one mailbox, one file — not an all-or-nothing recovery event.

This module runs on sample data until an admin connects real Microsoft 365 and storage credentials for their tenant — we label that honestly as "available, configure to activate" rather than dressing up a demo as a live backup. See the platform page for exactly where it stands.