Eight things can go wrong in Microsoft 365. We put all eight back.
Four Microsoft 365 families, eight restore surfaces, one engine. Mail, calendar, contacts, the archive folder, OneDrive, SharePoint, Teams, and Microsoft 365 Groups with Planner. Point-in-time, into your own S3 bucket — and every limit on this page says whose limit it is.
Four families. Eight restore surfaces. Named one at a time.
Most backup pages list four workloads and leave you to discover the rest at restore time. Calendar, contacts and the archive folder are not footnotes of “Exchange” — they are their own surfaces, with their own restore behaviour, and they are where a bad month usually starts.
Back into the live mailbox
Delta-synced. A single message, a folder, or the whole mailbox, at any retained restore point. Missing items are added and anything still there is left untouched.
Calendar
Calendar, mergedBack into the live calendar
You restore the calendar as a set and it is merged, not replaced: what is missing is written back and everything already there is skipped. So a single deleted meeting returns on its own, without duplicating the rest. An event edited since the backup can come back as a second copy rather than overwriting your newer version.
Contacts
Contact list, mergedBack into the live contacts
The same merge as the calendar, and the same honest caveat: a deleted contact comes back on its own, and one edited since the backup can return as a second copy. Restored contacts carry a defined set of fields rather than every property Microsoft holds.
Archive folder
One archived messageInto the main mailbox
The One-Click Archive folder is captured and restorable. It returns to the main mailbox or a staging folder, not into the archive folder itself.
OneDrive
One fileBack into the live drive
A file, a folder, or a whole drive as it stood at any retained point. A file that changed since the backup is kept and the backed-up copy lands beside it — or replaces it, if you choose that for the restore.
SharePoint
One document or list itemBack into the live site
Document libraries, custom lists, site pages and subsites, kept in structure. A list restores as a set that skips the items still present.
Teams
One channel messageInto a new channel in the same team
Top-level channel messages come back under their original author and timestamp. Channel files restore like any SharePoint file when the team’s site is backed up.
Groups & Planner
Captured and exportableExport, not re-injection
Both are captured, browsable and exportable for eDiscovery. Neither is written back into Microsoft 365 — for Groups conversations that is Microsoft’s ceiling, for Planner it is ours. Both are stated plainly below.
You choose what happens to the copy that is already there.
The question that decides whether a restore helps or hurts is not “can you get the data back” — it is “what happens to the version the user has been editing since”. Here are the three answers, and you pick one per restore.
Side by side
Everything lands in a clearly labelled staging folder. Nothing that already exists is touched. The safe default when you are not yet sure what the live state should be.
In place
Back where it came from. Missing items are added; anything still there is left alone. A file that changed since the backup is kept and the backed-up copy lands beside it — unless you choose replace, which is the ransomware answer.
Exact-state revert
Rolls a mailbox to a chosen point and removes what arrived after it. The mode for undoing a compromise. It soft-deletes rather than shredding, and it is refused outright while a legal hold is in force.
Every restore that writes to live data waits for an explicit approval — including an administrator’s own request, and including an impersonating administrator’s. Nothing executes just because it was asked for. A restore preview shows the add and skip counts first, so the approver is agreeing to a number rather than to a button. Ask your current vendor whether a restore into live data can be executed without a recorded approval.
Anyone can say “tamper-evident”. This is what ours actually does.
The usual claim is that each record holds the hash of the one before, so changing history breaks the chain. That claim is not true — of ours or of anyone’s. If an attacker can rewrite a record they can recompute every hash after it, and the result verifies perfectly. So we built the part that closes it instead, and we would rather explain it than repeat the slogan.
The chain catches two attacks
Alter one record and a per-record recheck fails. Delete one and a sweep finds the reference that no longer resolves, across the whole chain.
The signature closes the third
The chain’s head is anchored nightly and signed with an Ed25519 key held outside the database, so a rewrite-and-re-chain changes a head that was already signed. Every anchor on record carries its signature and the id of the key that made it; ask us for the public key and the anchor records and you can verify them independently of us.
Nothing is ever back-filled
An anchor attests the head as it stood when it was written and says nothing about earlier records. Back-filling would manufacture a chain of custody that never existed, which is the one thing an evidence product must not do.
Three key tiers, wrapped not shared
A master key wraps a per-tenant key; the per-tenant key wraps a per-object key. AES-256-GCM throughout. The tenant and per-object keys are random — not derived from a tenant id or a passphrase — so one client’s key tells you nothing about another’s. The one key we do derive is the one protecting a tenant’s Microsoft credentials, derived from that tenant’s own key so it is cryptographically separated from its backup content.
Destruction you can prove
Because every object has its own key, disposing of one means destroying that key — the object becomes unrecoverable while nothing else is touched. You get a SHA-256-sealed certificate recording what went, how, and when.
Immutability, conditionally
When your bucket has S3 Object Lock enabled we write every restore point under a lock — then re-read the object and compare the mode and the expiry before we call it locked. Requesting a lock and checking it stuck are different things.
On this side of the Atlantic every tenant brings its own bucket, so immutability is real exactly when you have switched Object Lock on. We will tell you whether yours is locked rather than assuming it — and if the bucket cannot hold a lock, the restore point still lands and we record that it is unlocked.
Your backups, and the platform that holds the evidence, are in the United States — the bucket, the console, the database and the audit chain. Bring your own S3 bucket in the region and account you choose, or use the US bucket we provide. We hold no SOC 2 or ISO 27001 report today; what we have instead is the mechanism described above, and you are welcome to audit it.
Ten dimensions, four products, two rows we do not win.
Columns are anonymised, and the field is larger than four — this is a selected comparison, not a census. The rows were written down before any vendor was looked up, which is why two of them are not ours to win. A column that wins everything is a column you should not trust.
| Kapsul8 M365 | Product A | Product B | Product C | |
|---|---|---|---|---|
| Restores in place, overwriting on request | Yes | No — always into a timestamped folder | No — non-destructive only | Yes |
| Smallest unit restored | One message, event, contact or file | File / mailbox item | File / mailbox item | File / item |
| Approval required before a live restore | Yes, by default | Not documented | Not documented | Not documented |
| Hash-chained audit with a signed anchor | Yes, signed anchor; public key on request | Audit export, 90-day window | Audit export | Audit report |
| Per-object destruction certificate | Yes, SHA-256 sealed | Appliance drive-wipe only | Not documented | Not documented |
| Your own S3 bucket, on the base product | Yes | Not found in their docs | Not found in their docs | Yes, with immutability |
| Published per-seat price | Yes — from $0.79 | Not published | Not published | Not published |
| Immutability mechanism named | S3 Object Lock, when your bucket has it | “Immutable”, mechanism not documented | “Immutable”, mechanism not documented | Object Lock on customer storage |
| Backup frequency | Up to 6×/day, 3× default | Up to 3×/day | 1×/day | 1×/day default |
| Retention ceiling | No product ceiling, 7-year default | Open-ended, but pruned on a schedule | Open-ended | 30–365 days unless contracted |
Competitor cells verified against each vendor’s own documentation as of 01/11/2026; these products change and several publish no date on the pages concerned. “Not found in their docs” means we could not establish it from their own documentation — not that the product lacks it. Two rows we do not win and have left in. Microsoft’s own backup service takes recovery points every ten minutes against our four hours — though on OneDrive and SharePoint that ten-minute granularity degrades to weekly snapshots after the first two weeks, while our four hours holds for the whole retention period. And one product in this channel covers the separate In-Place Archive mailbox while we do not. Both of those, and everything else this table leaves out, are in the limits section below — a table is the thing most likely to be screenshotted without its context, so read that too.
Every vendor hits these walls. Most pages don’t mention them.
One of the limits below is Microsoft’s, and we cite the API page and its date so you can check. The rest are ours. We are not going to describe our own gaps as platform constraints — if you are comparing products, the useful question is which walls are real and which are simply unmentioned.
Microsoft 365 Groups conversations cannot be put back
Microsoft platform limitGraph v1.0 lists the Application permission for POST /groups/{id}/threads as “Not supported.” (learn.microsoft.com, API reference, page updated 23/07/2025). No backup product operating app-only — ours or anyone else’s — can recreate a group conversation thread. We capture them, you can read and export them; nobody can re-inject them.
Planner is captured and exported, not restored
OursThis one is ours, and we are not going to blame the platform for it: Graph does support creating a plan app-only, with Tasks.ReadWrite.All. We have not built the restore path. It is on the roadmap and it is a gap, not a ceiling.
Item permissions are recorded, not re-applied
OursOneDrive and SharePoint item permissions are captured with the item, so you can see what the ACL was. Re-applying them on restore needs a Graph write scope your tenant admin has not consented to, so a restore lands the content and inherits the destination’s permissions. Restoring a file does not silently restore who could see it.
Nested folder structure is not rebuilt
OursA folder restore brings that folder’s items, not its subfolders, and a side-by-side restore lands everything in one clearly labelled staging folder rather than recreating the tree.
Teams replies, reactions and attachments are not restored
OursTop-level channel messages restore with their original author and time. Their replies, reactions, inline images and attachments do not, and a message whose author has left the tenant is reported rather than restored. Restored messages land in a new “(Restored)” channel, never in the live one.
Private and shared Teams channels are not restored
OursEach is declined, or skipped inside a whole-team restore, with the reason given — so a private channel is never quietly recreated as a standard one that everybody can read.
Chats are captured but not yet browsable or restorable
Ours1:1, group and meeting chats are in the backup. They are not yet exposed in the portals and are not written back into Teams. Chats hosted in another organisation’s tenant cannot be captured by any tenant-scoped connector, ours included, and the backup logs them as out of scope rather than skipping them silently.
Version history is captured as metadata, not as prior file bytes
OursWe record that the versions existed. We do not currently store every prior revision’s content, so we do not offer “restore version 4 of this file”. Each restore point is a point in time, and you pick the point.
The In-Place Archive mailbox is not covered
OursWe back up the One-Click Archive folder, which is a folder in the primary mailbox. The separate In-Place Archive mailbox is a different Microsoft feature and we do not yet read it — it needs a broader mail scope and fresh admin consent in every tenant. Some products do cover it. If your clients use it, ask us where this is before you buy.
Exports are EDRM EML with a loadfile, not PST
OurseDiscovery output is built for a reviewer and a review platform rather than for re-mounting in Outlook. If your workflow needs PST, say so — today it is a genuine gap.
Three calls every MSP knows.
“I deleted an email three weeks ago.”
Find it, restore that one message to the mailbox. Nothing else is touched.
“This file was saved over and the good copy is gone.”
Pick a restore point from before the overwrite. The old version comes back beside the new one, or in its place if you say so.
“Someone left and we need their calendar back.”
Their seat moves to archived at half rate when the mailbox leaves Microsoft 365, and everything stays restorable for the whole retention period.
Priced per seat. Published.
Starter $1.99, Growth $1.49, Scale $0.99, Volume $0.79, Enterprise custom. The same product in every band — the seat count you commit to sets the rate, with your band’s committed-seat floor where one applies. Seats whose mailbox is no longer found in Microsoft 365 archive at half the active rate instead of billing full price forever; pausing a mailbox does not archive it.
Frequently asked questions.
Point it at a tenant and watch the first baseline land.
Agentless, consent-based, no touch on the user. You will know inside an hour what it captures.