Backups, migration, evacuation, and recovery

#Backup design

Local backups help one node. Cross-node recovery requires every eligible Beacon to reach the same S3-compatible repository and have the credentials and encryption context needed to restore. The Beacon Compose configuration accepts BACKUP_ADAPTER plus S3_BUCKET, S3_REGION, S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY, S3_ENDPOINT, S3_PREFIX, and S3_USE_PATH_STYLE.

#Evacuation runbook

1. Mark the source node unavailable for new placement.
2. Verify a second Beacon is healthy and has capacity.
3. Create and verify a backup in shared storage.
4. Reserve the destination allocation and storage path.
5. Restore or redeploy at the destination.
6. Verify health, data, and public allocations.
7. Retire the source only after verification.

#Control-plane backup

PostgreSQL is dumped by the postgres-backup sidecar on POSTGRES_BACKUP_INTERVAL_SECONDS, keeping POSTGRES_BACKUP_RETENTION_DAYS, and can push to S3 settings when configured. Inspect status with ./scripts/status.sh and the sidecar logs; keep a tested copy off the host.

docker compose -f compose.yml -f compose.production.yml --env-file .env logs --tail 100 postgres-backup
# confirm recent dumps and pushgateway backup_last_success_seconds

#Recovery limits