Backup vs. archive: what each is for, and why one does not replace the other

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-29

What is a backup for, and what is an archive for?

The SNIA Dictionary, the storage industry's shared vocabulary, defines the two by their purpose. A backup is a collection of data stored for recovery in case the original is lost or becomes inaccessible. An archive is a collection of data objects in a storage system whose primary purpose is the long-term preservation and retention of that data. NIST's definition of a backup in SP 800-34 says the same thing from the contingency-planning side: a copy kept so that systems can be recovered.

In everyday terms, a backup answers "Can I get this back?" and an archive answers "What did this say, and can I prove it?" The first is about the data you work with, the second about records you must be able to produce later.

How do a backup and an archive compare?

Archiving vs journaling: what is the difference?

Journaling is not a kind of archive. It is one way of feeding an archive with mail. In Exchange and Exchange Online, a journal rule makes the server send a journal report for every message in its scope (internal messages, external messages or all of them) while the message passes through the organization's mail transport. The original message is attached to the report unaltered, and the report lists its sender, subject, message ID and recipients; Microsoft calls this envelope journaling.

An archive is what receives those reports and keeps them: each record once, for the retention period, with search, export and proof that nothing was changed. Journaling decides when and how mail is captured, archiving decides how long and how safely it is kept. One does not work without the other:

• Journaling without an archive produces a stream of reports and nothing more. Exchange Online cannot even keep them itself: the journaling mailbox may not be an Exchange Online mailbox, so the reports have to go to an on-premises system or an archiving service.
• An archive without journaling has to capture mail another way: from the mailbox after delivery (through an API or IMAP), from copies a mail provider forwards, or by importing old mail. Capture from the mailbox comes later than journaling, so a mail deleted in between can be missed.
• Neither covers the past. Journaling starts with the rule; mail from before that day has to be imported once.

Microsoft itself calls journaling an older feature that moves data outside Microsoft 365 and recommends its own retention where it is enough. Journaling stays the capture method for organizations that need a copy outside the tenant. The word also has an unrelated meaning in storage: a journaling file system records pending changes so that it survives a crash, which has nothing to do with keeping mail.

In Restow, Business and Service Provider receive Exchange Online journal reports over SMTP (this needs a TLS certificate of your own) and copies a mail provider forwards; since 0.4.4 they can also capture from the mailbox with Microsoft Graph and IMAP sync, near-time and not complete. Every edition can import old mail with archiving. The box "How Restow handles this" below has the details.

Why is retention not recovery, and recovery not retention?

The word "retention" covers two different things. Backup retention decides how many restore points you keep and for how long: an operational choice about how far back you may need to go. Record retention decides how long a record must stay available: a legal or contractual duty. A backup that keeps every restore point for 30 days and thinned ones for a year cannot answer a question about a mail from six years ago, and an archive that holds every mail for eight years cannot put a mailbox back the way it was last Tuesday.

Microsoft draws the same line inside Microsoft 365. Its retention policies and labels preserve content for compliance and do not create restore points you can roll back to, which is why retention is not a backup.

Can one system do both?

It can, if it keeps the two sets of rules apart. What matters is not the product but four properties: when data is captured, who can delete it, whether older copies are thinned out and whether the store can prove it was not changed. If one store is run on backup's terms, three things go wrong for records:

• It rotates. Restore points are pruned by design, so the record is gone when its last restore point expires.
• It captures late. A mail deleted before the next run is not in the backup at all.
• It can be changed. An administrator or an attacker with the same access can delete it.

If the same store is run on archive's terms, operational recovery becomes needlessly rigid and expensive: every restore point is kept for the full record period, and getting something back means retrieving and re-importing rather than rolling back.

Keep the word "archive" apart from a third meaning too: some older products move or stub mail out of the mailbox to save space. That is storage management, not the independent copy discussed here.

What does the GoBD angle change for a German business?

Business email that is a commercial letter or relates to a booking is a record under German law. It has to be kept for six years (commercial letters), eight years (booking vouchers) or ten years (books, records and annual accounts), and the period starts at the end of the calendar year in which the letter was received or sent (§ 147 AO, § 257 HGB). The GoBD, the finance ministry's guidance on keeping such records electronically, add requirements for how: complete, correct, timely, orderly, unalterable, traceable and machine-evaluable, with procedure documentation.

Read against the table above, a rotating backup is a poor fit for those requirements. It forgets by design, it sees only what existed at the moment of a run and the people who run it can delete it. That does not mean you do not need backups: you need both. There is also no GoBD certificate to hold: the tax authorities issue no positive attestations, so responsibility stays with the taxpayer. What a tool can offer is to be designed for GoBD-compliant use and to say plainly which measures it takes. This page is not legal or tax advice; have your tax advisor confirm what applies to you. Details are on the page about email archiving under the GoBD and in GoBD and email archiving, explained. Which email falls under which period is on the page Email retention periods in Germany, and what belongs in the procedure documentation is on Procedural documentation for email archiving.

The two duties can also pull against each other. A legal duty to keep a record is one of the exceptions to the right to erasure in the GDPR; see GDPR and backups.

How can a small business run both?

1. Decide which data are records (business mail, invoices, contracts) and which is working data. The first group goes into an archive, the second needs only backup.
2. Capture records as early as the system allows, and write the rule down in your procedure documentation.
3. Back up everything, the archive included. The 3-2-1 rule applies to the archive as much as to any other data.
4. Set the two retention rules separately: restore points in age tiers (see grandfather-father-son rotation), records in years from the legal rule.
5. Test both. Restore from a backup into a test target, and retrieve a record from the archive and check its proof.
6. Write down who may delete what, and who may place or release a hold.

How Restow handles this

Restow keeps backup and archive in the same storage and under separate rules. Neither deletes anything from your mailbox: both are additive copies.

The backup side

Backups run on a schedule you set in a job, and restore points are kept by a retention policy: age tiers for mail and Microsoft 365 jobs, daily, weekly and monthly counts for servers, clients, file shares and Proxmox VE jobs. Restores are non-destructive by default, and a weekly restore check reads a sample of each backup back. See Microsoft 365 and IMAP backup, restore and verification.

The archive, in every edition

An append-only store for mail with a SHA-256 hash chain. Chain verification checks every link, the daily anchors that are written each night and, if you want, a sample of message contents. Archived mail can be searched (subject, addresses and, for imported mail, body text, not attachments), read in Restow, downloaded as .eml and exported as EML in a ZIP file or as MBOX. In every edition the archive is filled by mail import with the option to archive at the same time; the retention period then starts on the import date. See mail file import, export and the archive.

What Business and Service Provider add

The layer designed for GoBD-compliant use: journal receipt of Exchange Online journal reports over SMTP and, for IMAP providers and Google Workspace, copies the provider forwards (both are captured in transport, before a user can touch the mail; the receiver needs a TLS certificate of your own), retention with an enforced deletion run, and legal hold per tenant or per mailbox, released only with a reason and audited. Since 0.4.4 they also add capture from the mailbox itself: Microsoft 365 by Graph change notifications, IMAP and Google Workspace by IMAP sync. That capture is near-time: Restow fetches the mail shortly after delivery, and Restow labels it as such and does not claim it is complete. Restow is designed for GoBD-compliant use and is not certified; no such certificate exists.

Limits you should know

• The archive period is fixed at 8 years, counted to the end of the year of capture. No screen or API sets another period yet.
• What reaches the archive is decided per mail job by the capture ways you choose (Graph or Exchange journaling for Microsoft 365, IMAP sync or forwarded copies for IMAP and Google Workspace) and by what you import. A mail moved or deleted right after delivery can be missed by the near-time ways, and Restow cannot see whether a Microsoft 365 tenant keeps deleted mail, so an administrator confirms it. These ways were tested against simulated services only. Choosing archive or backup per mailbox inside a job, archive proofs and search by end users are planned.
• The hash chain makes a change detectable, not impossible. Immutability is a setting of each repository and is off until an administrator turns it on. On S3 with Object Lock it locks the backup data and, because archived message content goes into the same chunk store, the packs that hold that content; you choose the lock period and the mode (compliance or governance). The archive's item records keep their own retention. On local disk and NFS the storage cannot enforce it: Restow's own code only delays deletion, which the interface calls a deletion delay and says is not immutability. All of it was tested against a simulated S3 service with Object Lock, not yet against a real one. See immutable backups, WORM and air gaps and the immutable backups section of the storage page.
• Retention of backups never removes the newest restore point of an object, and nothing under a legal hold is pruned. A restore point that is still locked stays until its lock ends, and the restore points of an object with a retention hold stay until an administrator ends the hold.

The documentation explains the split in detail: Backup vs. archive.

Frequently asked questions

Sources

Read on 29 October 2026.

1. SNIA Dictionary (generated 28 April 2026): backup and archive. A backup is for recovery, an archive for long-term preservation and retention
2. NIST glossary: backup (from NIST SP 800-34 Rev. 1). A copy of data and software kept so that systems can be recovered
3. § 147 Abgabenordnung (AO). Retention periods of 6, 8 and 10 years, their start at the end of the calendar year, storage on data media
4. § 257 Handelsgesetzbuch (HGB). The same periods under commercial law
5. Bundesministerium der Finanzen: GoBD, BMF letter of 14 July 2025 (second amendment of the letter of 28 November 2019). The GoBD set requirements for how business records are kept, not only for how long
6. Microsoft Learn: Journaling in Exchange Online. Journal rule scopes, what a journal report contains, and why the journaling mailbox cannot be in Exchange Online
7. Microsoft Learn: Learn about retention policies and labels to retain or delete. Retention as a compliance tool: what it keeps, deletes and for how long
8. Restow documentation: Backup vs. archive. How Restow keeps the two apart
9. Restow documentation: Archive and journaling. The capture ways Restow offers and what each one sees

Related articles

• Email retention periods in Germany Which emails are commercial letters (6 years), accounting vouchers (8 years) or books (10 years), when the period starts, when you may delete, and what the GDPR adds. Not legal advice.
• Procedural documentation for email archiving What the GoBD ask of a procedural documentation (Rz. 151 to 155), its usual parts, what an email archive needs in it, and a template to download. Not legal advice.
• GDPR and backups What Article 17 asks of a backup, what the EDPB and German authorities say, why backups usually expire, and where locks and holds collide with an erasure request. Not legal advice.
• Does Microsoft 365 back up your data? What Microsoft keeps, for how long (recycle bins, version history, retention), why retention is not a backup, and what Microsoft 365 Backup is.
• The 3-2-1 backup rule Three copies, two kinds of storage, one location apart, and the extension with an immutable copy and zero errors. With a worked Microsoft 365 example.
• Grandfather-father-son (GFS) rotation Daily, weekly, monthly and yearly restore points with a calendar example, how it differs from keeping every backup for N days, and how it maps from tape to disk and object storage.
• Backup glossary reference Short definitions of backup, restore and retention terms, from 3-2-1 rule to WORM, with links to the articles and features pages that go deeper.