Technical Reference
Snapshots and Redundancy
MP-OPT combines availability controls with independently encrypted recovery copies. Each mechanism has a different recovery point, custodian, and failure boundary.
Three independent resilience layers
Availability, recent redundancy, and disaster recovery solve different problems and must not be treated as interchangeable.
1. Live service
The holder serves requests. In HA, either VPS may hold the writer lease.
2. Peer recovery point
A recent accepted complete bundle supports failover after one VPS is lost.
3. External recovery copy
An independently encrypted and verified snapshot protects against both VPSs, corruption, and operator mistakes.
Copies and their purpose
| Copy | Contains | Protects against | Does not protect against |
|---|---|---|---|
| Schedule history | One event's published schedule state | Unwanted schedule changes | VPS or installation loss |
| HA peer bundle | Complete database plus shared configuration and shared service secrets | Loss of one VPS, subject to its accepted recovery point | Corruption copied from the holder or loss of both VPSs |
| Recovery snapshot | Database, shared configuration, secrets, and applicable topology metadata | Installation loss, corruption, and return to an earlier state | Loss of the matching private recovery identity |
| Portable external copy | Encrypted snapshot package and public receipt | Loss or compromise of both VPSs | Failure to keep a separately protected private identity |
Recovery snapshot contents
Included
- PostgreSQL custom-format dump
- Shared application configuration
- Protected shared service secrets
- Applicable proxy topology metadata
- Manifest paths, sizes, modes, and SHA-256 values
- Outer hash and public receipt
Excluded deliberately
- Operator's private age recovery identity
- SSH private keys
- Node identities and witness tokens
- Everything under
/etc/mp-opt-ha - Peer-local database password
- Unrelated workstation credentials
Recovery objectives
- The peer replication interval is configurable from 5 to 1440 minutes and defaults to 15 minutes.
- All writes after the most recent complete accepted peer bundle may be lost during failover.
- The interval is a target only while the peer, SSH, witness, and replication job remain healthy.
- External snapshot age determines how far a total-site restore returns the installation.
- Automatic failover is roughly five minutes plus promotion and health-routing delay, not zero downtime.
Use the Recovery Snapshots runbook to create and verify archives. This page explains the model but does not replace the guarded operator workflow.