Disaster Recovery

Sovereign backup with Shamir secret sharing. No cloud dependency.

Overview

Ephemera encrypts critical data (CA keys, database) with a random password, then splits that password into Shamir shards. No single person can restore the backup, but a quorum can.

Create Backup

Generate encrypted backup and split the password into shards:

ephemera backup-create --k 3 --n 5 --out-dir ./backup

This produces:

ephemera_backup.enc — The encrypted archive
backup_shard_1_of_5.json through backup_shard_5_of_5.json — Password shards

Shard Distribution

Store each shard in a separate, secure location with different custodians. The encrypted backup file is useless without the required number of shards.

Restore Backup

Restore using the encrypted file and any k shards:

ephemera backup-restore \
  --backup ./backup/ephemera_backup.enc \
  --shards ./backup/backup_shard_1_of_5.json \
           ./backup/backup_shard_2_of_5.json \
           ./backup/backup_shard_4_of_5.json \
  --out-dir ./restored

In this example, 3-of-5 shards are required. Any 3 shards can reconstruct the password. The specific shard numbers do not matter.

Parameters

Parameter	Description
`--k`	Threshold: minimum shards required to restore
`--n`	Total number of shards to generate
`--out-dir`	Directory for output files
`--backup`	Path to encrypted backup file (restore only)
`--shards`	Paths to shard files (restore only)

Security Properties

Backup is encrypted with AES-256-GCM.
Password is never stored; only shards exist.
Shards are portable JSON files (no QR codes).
Air-gap compatible: no network required for recovery.

CA Key Rotation

Ephemera supports zero-downtime CA key rotation. Old keys remain trusted during the transition period:

ephemera rotate-ca

The rotation lifecycle maintains active, previous, and next keys. Existing certificates remain valid until expiry.