Aeion Aegis for Disaster Recovery
Disaster recovery covers the failure modes nobody plans for at 2 AM: VPS hardware loss, region outage, ransomware encryption, AWS account compromise, accidental `rm -rf /var/lib/postgresql`. Aegis's four-layer defense + BYOB off-machine storage is the recovery path. This page is the runbook — three concrete failure-mode walkthroughs with measured RTO targets, plus brutal honesty about what Aegis can't recover (and what you still need to plan separately).
The Three DR Scenarios Aegis Is Built For
`
Scenario 1 Runbook — VPS Hardware Loss
`
Scenario 2 Runbook — Ransomware Encryption
`
Scenario 3 Runbook — Cloud Region Outage
`
What Aegis Does NOT Cover For DR
Honest list:
Recommended DR Practices Alongside Aegis
`
FAQ
30-90 minutes typical for a 50 GB DB on common cloud providers. Scales linearly with DB size + cloud provisioning latency.
No. Aegis is a recovery tool, not a topology. For sub-5-minute RTO via active-active, you need separate Postgres streaming replication. Aegis runs alongside.
No (yet). Aegis surfaces health signals + emits alerts; a human (or your orchestration layer) initiates the restore. Auto-failover requires distributed-consensus design that's deliberately out of scope for v1.
Aegis itself doesn't manage bucket-level immutability. If you configure S3 Object Lock (COMPLIANCE mode) or versioning on your own bucket, that's your defense against a leaked-credential attacker deleting objects during the retention window. Aegis restores from the bucket you configure; the immutability posture of that bucket is on you.
For most tenants, no — a single well-configured bucket is sufficient. For enterprises with regulatory requirements (e.g., "data must survive any single cloud provider failure") or extreme paranoia, set up your own cross-region or cross-cloud replication on the bucket side. The complexity is in DNS + traffic-redirect orchestration and your storage provider's replication setup, not in Aegis itself.
30 days is the default retention window, configurable per tenant. Longer windows have larger storage cost but give you more recovery flexibility for delayed-detection scenarios (e.g., "we just noticed a bug that's been corrupting data for 3 weeks").
Yes. TLS 1.3 to your S3-compatible endpoint. With CMK, payload is also encrypted client-side before upload (zero-trust posture).
Not Aegis storage cost. It's the time to design + drill the runbook. Most teams under-invest by 10x in DR drills and over-invest in storage redundancy. Schedule the quarterly drill; it's the single highest-leverage thing.
Partially. pgBackRest needs filesystem access to the data directory, which managed Postgres usually doesn't expose. On RDS, you can use AWS-native PITR alongside Aegis's Layer 3 logical snapshots + Layer 4 application time travel. Layer 2 PITR requires Postgres-on-VM topology.
~60 seconds once Layer 2 PITR is configured (the `archive_timeout` floor on pgBackRest WAL push). Under steady write load, typically 30 seconds. Before PITR is configured, Layer 3 daily snapshots alone give a 24-hour RPO.
Yes. Aegis continuously tracks archive lag, time since the last base backup, and recovery-window shrinkage, and fires alerts when any of these cross a safety threshold.