Backup vs. archive
Restow 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 (since 0.1.0) | |
|---|---|---|
| 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 | By a retention policy (choosing one in the interface is planned; kept indefinitely until then) | 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. Restow 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. Restow 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 Restow:
- Backup runs on a schedule, through Microsoft Graph delta queries (Exchange Online, OneDrive), IMAP sync or, for servers and clients, the Restow agent, and its retention is an operational choice: how many points in time you want to be able to return to.
- Archive (since 0.1.0 in every edition; journal receipt, retention and legal hold from Business; see Archiving) is captured through Exchange Online journaling, which gives Restow a copy of a message before a user can touch it at all, and is then designed to be held immutably, with a hash chain checked against outside anchors and, by default, planned hardware object-lock, for a retention period set by policy (matching the German commercial and tax periods) that nobody, including an administrator, can shorten before it ends.
Restore points, not a “server backup” feature
Section titled “Restore points, not a “server backup” feature”Each backup run produces one restore point, Restow’s own plain-language name for what the underlying code calls a snapshot: the state of one mailbox, one OneDrive, or one IMAP account at the moment that run finished. An incremental run only re-reads what changed, but the restore point it produces is still a complete point-in-time view of the whole object, not a diff you would need to replay against older ones. Unchanged items are simply carried forward from the previous restore point.
Restoring from a restore point is not an all-or-nothing operation, and it is not a feature reserved for server-style file backups: the same mechanism restores a single mail, a single file, a whole folder, an older version of a file that Restow itself backed up (an older version OneDrive kept on its own is download-only, not restorable; see Backup and restore), or the entire mailbox/OneDrive/IMAP account at that point in time, for Microsoft 365 and IMAP alike. See Backup and restore for how that works in the interface, and How Restow checks that a backup can be restored for how the latest restore point is checked by sampled read-back, not just stored.
Servers and client computers are backed up differently, by the Restow agent into restic repositories; see Endpoint backup. Mail you import from files is not backed up at all: it is stored as an imported mailbox, and you can optionally archive it too, with retention counted from the import date; see Mail file import and export.
How long a restore point is kept
Section titled “How long a restore point is kept”Backup retention is an operational choice, separate from archive retention: how many restore points you want to be able to go back to, not a legal minimum. The engine that prunes restore points by policy already runs daily, quietly removing what a policy says is no longer needed, always keeping at least the newest completed restore point of every object, and never pruning anything under an active legal hold (legal hold itself is also planned; there is no interface or API yet to place one). Choosing that policy in the interface, with a suggested default, is planned but not yet available; until it ships, a protected object without a policy keeps every restore point indefinitely.
This is unrelated to archive retention (6, 8, 10 years or unlimited, matching German commercial and tax periods; see Archive and journaling), which governs how long the separate, unalterable archive copy is kept, once that ships.
Mailbox cleanup is a separate decision
Section titled “Mailbox cleanup is a separate decision”Whether your organization removes old mail from a live mailbox, through Exchange Online’s own retention or archive policies, a manual cleanup, or simply a user deleting things, is entirely your own decision, made in Exchange Online itself, not in Restow. Restow does not need mail to stay in the mailbox to have backed it up or archived it, and cleaning up a mailbox does not remove anything from an existing Restow restore point or archive copy; the two are independent.
Choosing per mailbox: back up only, or back up and archive
Section titled “Choosing per mailbox: back up only, or back up and archive”Not every mailbox needs the same protection. A shared mailbox like bestellung@ or noreply@ is often worth backing up, so it can be recovered if something breaks, without needing the same permanent, unalterable archival that regular staff correspondence gets for evidentiary reasons. Once the archive ships, choosing this per mailbox is planned: the same rule mechanism the backup scope already uses (everyone, a group, an exclusion list, individual overrides) will apply to archive scope too, shown side by side as separate Backup and Archive columns in Protected objects. The planned default, once archiving exists, is that every mailbox is archived; excluding one, for a mailbox like noreply@, is a deliberate, audited choice, not a quiet default. See Archive and journaling for the full design.
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 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”- How Restow checks that a backup can be restored: what the automated recovery-readiness check does, and what it does not check yet.
- Archive and journaling: journaling, the hash chain, WORM, retention, legal hold and per-mailbox archive scope, in full.
- GoBD and evidence: what “unalterable” and “evidence” actually require under German law, and how Restow’s archive design targets that.
- Archiving: the full design and its current (in-development) status.