Skip to content

Archiving

Backup and archive solve different problems. See Backup vs. archive if you have not read that page yet. In short: backup is for getting data back; the archive is for keeping unalterable evidence of business email, built for German GoBD requirements (see GoBD and evidence). The full technical design (journaling in detail, the hash chain, WORM/Object Lock, and per-mailbox archive scope) is on Archive and journaling; this page is the summary.

  • Exchange Online journaling (the primary path, Business and above): every journaled message is captured before a user can read, change or delete it, by an SMTP journal report Restow receives directly. The underlying journal rule can be scoped to everyone in the tenant or to selected recipients/groups. Operator and Microsoft 365 steps, the TLS certificate the receiver needs and the status on the Archive page are on Exchange journaling.
  • Graph sync, as a supplement: captures what already existed in a mailbox before journaling was switched on. Anything captured this way is marked as “captured after the fact”, because the hash-chain protection only starts once Restow has the item.
  • IMAP archiving: a continuous sync for mail providers without journaling, the best available approximation, documented as such rather than presented as equivalent to journaling.
  • Append-only store with a SHA-256 hash chain and a chain verification that shows whether anything was altered or removed.
  • Full-text search across the archive for administrators.
  • Retention policies with an enforced deletion run (Business and above): only expired, non-held objects are deleted.
  • Legal hold (Business and above): suspends deletion for what it covers until it is released.
  • Mail imported from files: when you import a legacy mailbox from EML, MSG, MBOX, ZIP or a MailStore export, you can archive it at the same time (capture route file_import). Retention starts at the import, not at the date of the mail, and the mail’s own date is kept and used in search and display. Immutability applies from the moment Restow has the item, as with Graph sync. See Mail file import and export.
  • Export of archived mail as EML files in a ZIP (with MANIFEST.csv and SHA256SUMS) or as MBOX, through Mail file import and export. Every request and download is written to the audit log.
  • Self-service archive search for end users: searching their own mail history and restoring (non-destructively) or downloading what they find. See Usage.
  • Auditor export and evidence report: an EML/ZIP export that also carries the chain values, and a signed evidence report per tenant. A plain export with a manifest and checksums is already available (see above).
  • WORM by default: S3-compatible object storage with Object Lock in COMPLIANCE mode as the default archive target, and an explicit, audited opt-out for filesystem targets (local path, NFS or SMB) that is then shown as “storage target without hardware WORM”. See Regulations for whether GoBD actually requires WORM specifically.
  • Choosing per mailbox whether it is backed up only, or backed up and archived, through the same rule mechanism the backup scope already uses, with separate Backup and Archive columns in Protected objects. See Archive and journaling.
  • Not “GoBD-certified”. Restow is built for German GoBD requirements, with the specific measures named. Whether that meets your organization’s needs is ultimately something your own tax advisor confirms, not a certificate any software can issue.
  • Not a substitute for review by a tax advisor or a data protection officer.
  • No guarantee of completeness for IMAP archiving without journaling.