Skip to content

Large deployments: disaster recovery#

This documentation applies to Piler enterprise edition 2.2.4+

Revision #1

Publication date: 2026-OCT-18

A separate disaster recovery (DR) site keeps the archive available when the production site is down as a whole. Each site has the layout described in architecture.

Your mail server sends every email to both sites, and both archive it independently.

                 Your mail server
            ┌───────────┴───────────┐
     ┌──────▼───────┐        ┌──────▼───────┐
     │ Piler, prod. │        │  Piler, DR   │
     └──────────────┘        └──────────────┘
  • Both sites always hold all the emails: there is no replication between them, no replication lag, and the DR site is tested continuously, since it archives all the time.
  • Failover: point your users (DNS or the load balancer) to the DR site.
  • Your mail server has to send each email to two archive addresses, see mail server integration.

Changes made in the archive after archiving are not carried over between the sites: removals and GDPR erasures, legal holds, tags and notes, user settings. Each site applies the changes made on it. Plan for it:

  • Carry out removals and GDPR erasures on both sites. This one matters for compliance: an email erased at the production site would otherwise still be found at the DR site.
  • Apply legal holds on both sites, so that the DR site doesn't purge what is on hold.
  • Tags, notes and user settings made at the production site are not available at the DR site after a failover.

Replicating the production site#

An alternative is to replicate the production site to the DR site: database replication plus replication of the stored emails (e.g. object storage replication between the sites). It carries every change over, at the cost of more moving parts and a replication lag.