Backups, migration, evacuation, and recovery

A backup is only useful after a verified restore on a node that can actually host the workload.

Repository-validated operator guidance View source ↗

#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

Safe sequence

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

Use the supplied scripts

./scripts/upgrade.sh
# review the backup directory configured by POSTGRES_BACKUP_HOST_DIR
./scripts/rollback.sh list
# restore only after taking a fresh backup and reading the command
./scripts/rollback.sh db /var/backups/gamepanel/postgres/gamepanel-<timestamp>.dump

#Recovery limits

Restore-oriented recovery

The current configuration provides backup and restore paths. It is not evidence of automatic ownership failover for a running stateful workload. Practice the runbook with a non-critical workload.