Backup vs. archive
Osiris keeps backup and archive in the same underlying storage, but they answer different questions, follow different rules, and — this is the point people usually expect wrongly — neither one deletes anything from your mailbox.
The short answer
Section titled “The short answer”| Backup | Archive | |
|---|---|---|
| Question it answers | “Can I get this back?” | “Can I prove what this said, and when it arrived?” |
| Captured | On a schedule (delta sync) | Before a user can read, change or delete it (journaling) |
| Kept how long | Backup retention (rotated/pruned over time) | Legal retention: 6, 8 or 10 years, or unlimited, by policy |
| Deletable early | Yes, by policy or an administrator | No — not by anyone, including an administrator, before the retention period ends |
| Effect on the live mailbox | None | None |
| Restore | Into the original or another mailbox, non-destructively | Same: non-destructive restore, or download |
Neither one is “copy and delete from the mailbox”
Section titled “Neither one is “copy and delete from the mailbox””This is worth stating plainly, because “archiving” is sometimes assumed to mean move mail out of the mailbox to save space, the way some legacy archiving products stub or remove the original after capturing it. Osiris does not do that. Both backup and archive are additive: they create an independent copy elsewhere. What happens to the original in the live mailbox afterwards is entirely up to your organization’s own Exchange Online retention policies, holds, and the user — Osiris does not reach into a mailbox to delete anything as a side effect of backing it up or archiving it.
So to answer the question directly: backup is a recoverable copy of your mailbox, and archive is an independent, unalterable copy kept for legal evidence — neither one is defined by removing the original from the mailbox.
Why they need to be different systems
Section titled “Why they need to be different systems”If backup and archive were the same mechanism, one of two things would go wrong:
- Run it on backup’s terms (rotated, prunable, captured on a schedule), and it stops being reliable evidence: an item captured hours after arrival, on a system an administrator can delete from, does not satisfy “timely” and “unalterable” record-keeping.
- Run everything on archive’s terms (immutable, indefinite retention), and ordinary operational recovery becomes needlessly rigid and expensive for data that never needed to be legal evidence in the first place.
Concretely, in Osiris:
- Backup runs on a schedule, through Microsoft Graph delta queries (Exchange Online, OneDrive) or IMAP sync, and its retention is an operational choice — how many points in time you want to be able to return to.
- Archive (in development — see Archiving) is captured through Exchange Online journaling, which gives Osiris a copy of a message before a user can touch it at all, and is then held immutably — with a hash chain and, on storage that supports it, hardware object-lock — for a legally set retention period that nobody, including an administrator, can shorten.
Restoring from either one
Section titled “Restoring from either one”Whether you restore from a backup or, later, from the archive, the same rule applies: restore is built to be non-destructive. By default it does not overwrite an existing original in a mailbox — restored items go in alongside what’s there, and every restore is logged; see Backup and restore for the current beta’s one exception (an explicit “Replace” mode being removed) and what non-destructive restore looks like in practice, and First steps for the end-user side.
Where to read more
Section titled “Where to read more”- GoBD and evidence — what “unalterable” and “evidence” actually require under German law, and how Osiris’s archive design targets that.
- Archiving — the full design and its current (in-development) status.