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 | |
|---|---|---|
| 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 (Exchange Online journaling, or a copy that the mail provider forwards; Business and above), shortly after delivery from the mailbox (Graph capture and IMAP archiving, near-time and not complete; Business and above, since 0.4.4), or when you import it from files with the archive option (every edition) |
| Kept how long | By a retention policy (a tenant default plus overrides for single objects, on the Retention tab of the tenant setup); without a policy every restore point is kept | Legal retention: a fixed 8 years, ending on 31 December of the year of receipt plus 8 years (no setting for another period yet) |
| Deletable early | Yes, by policy or an administrator, unless the repository has immutable backups turned on (since 0.4.0): then the storage refuses to delete a locked restore point before its date, and retention leaves it alone until then. An unresolved ransomware finding also pauses retention of its object | Not through Restow: the application has no path to change or delete an item before the retention period ends, and a legal hold stops even the scheduled deletion. On local and NFS targets the application enforces this, not the storage (see what the storage target enforces) |
| Effect on the live mailbox | None | None |
| Restore | Into the original or another mailbox, non-destructively | Export as EML in a ZIP or as MBOX; restoring archive items back into a mailbox is planned |
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, tamper-evident 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 meet the requirements for timely capture and protection against change.
- Run everything on archive’s terms (append-only, long 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 (in every edition; journal receipt, capture from the mailbox, enforced retention and legal hold from Business; see Archiving) is filled by Exchange Online journaling (Business and above), which gives Restow a copy of a message before a user can touch it at all, by copies that a mail provider forwards, by capture from the mailbox shortly after delivery (Graph for Microsoft 365, IMAP archiving for IMAP and Google Workspace; near-time and not complete), and by mail import with archiving (every edition). It is append-only, with a hash chain that makes changes detectable, for a fixed retention period of 8 years (see GoBD and evidence for the German periods) that the application has no path to shorten before it ends. On local and NFS targets that is enforced by the application, not by the storage; on S3 with Object Lock, the archive item records are locked to the end of the retention, and the message content is locked with the backup data where immutable backups are turned on for the repository. Object Lock that follows the archive’s own retention is planned. See Archive and journaling.
Journaling is not a mailbox backup
Section titled “Journaling is not a mailbox backup”Journaling captures each mail as it passes through the Exchange Online transport, in the state at sending, and it keeps nothing else: no calendars, contacts, folders, read status or later changes. Capture from the mailbox (Graph, IMAP archiving) takes each mail shortly after delivery and keeps the same: the mail, not the mailbox. The mailbox backup restores folders, calendar, contacts and whole mailboxes as they were at a restore point, but it misses mail that arrives and is deleted between two runs, and it is not tamper-evident. To restore, you need the backup; to prove, you need the archive; with an archive, a less frequent backup is enough (the job editor suggests every 8 hours). The full comparison is on Archive and journaling.
Existing mail and the same mail twice (since 0.4.4)
Section titled “Existing mail and the same mail twice (since 0.4.4)”When capture from the mailbox (Graph or IMAP archiving, Business and above) is switched on for a mailbox, mail that is already there is taken over once and marked as captured afterwards, because the archive cannot show that nobody changed it before capture began. The same mail that reaches the archive by several ways, say through forwarding and through IMAP archiving, is recognized by Message-ID and content and kept as one item, with the stronger way; search hides the weaker capture unless you ask for it. None of this touches the mailbox backup. See Archiving for both, and its known issues for what was tested and what is not detected.
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. The VMs and containers of Proxmox VE (a preview) are backed up as changed disk blocks and through restic; see Proxmox VE 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. Tenant administrators set it on the Retention tab of the tenant setup (Tenant settings → Backup retention): a tenant default plus overrides for single protected objects. The engine that prunes restore points by policy 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 (Business and above) is placed per tenant or per mailbox, with a reason, and is audited. A protected object that no policy applies to keeps every restore point. Two things can keep a restore point longer than its policy says: an unresolved suspicious finding of ransomware detection pauses retention of that object until an administrator resolves it (since 0.4.0), and on a repository with immutable backups a restore point stays while its lock has not run out, so the space comes back later.
This is unrelated to archive retention (a fixed 8 years in 0.4.7; see Archive and journaling), which governs how long the separate archive copy is kept. Only the daily deletion run (Business and above) deletes from the archive, and never while a legal hold applies.
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 archival that regular staff correspondence gets for evidentiary reasons. Choosing this per mailbox is planned and not in 0.4.7: the same rule mechanism the backup scope already uses (everyone, a group, an exclusion list, individual overrides) is meant to apply to archive scope too, shown side by side as separate Backup and Archive columns on the Protection tab. Today, what reaches the archive is decided per kind of mailbox in the job (the capture ways, since 0.4.4), by the journal rule you set in Exchange Online and by what you choose to import. See Archive and journaling for the design.
Restoring from either one
Section titled “Restoring from either one”Restore from a backup 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. Mail in the archive is taken out as an export (EML in a ZIP, or MBOX; see Mail file import and export). Restoring archive items back into a mailbox, including for end users, is planned.
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, mail import, the hash chain, what the storage target enforces, retention, legal hold and per-mailbox archive scope, in full.
- GoBD and evidence: what the GoBD requirements “unalterable” and “timely” actually mean under German law, and how Restow’s archive targets them.
- Archiving: the summary and the current status (available and planned).
- Immutable backups and Ransomware detection: how backups are protected against deletion, and how suspicious restore points are marked.