Backups and data recovery

Backup preserves the database, images, and release information in one recovery point. For a manual dev transfer, use a dump and file archive.

1. Check whether backup is enabled

Open the profile in Deployment → Deployment environments and choose Backup destination. In JSON, this is backup.kind:

For prod-local, the backup directory is calculated from the project path and profile name. For server Local directory, set the path in the UI profile. A local copy on the same disk does not protect against machine loss — also save it outside the server. Backup and working images must use different S3 bucket/prefix locations.

If None is selected, enable Local/S3 through reconfigure first. Changing storage does not move old points; disabling backup does not delete them.

2. Create a point

Work from the project root: Source on the VPS as the deployment user, Archive/Registry on the controlling computer, and prod-local on your computer.

bash ./deploy/control backup --env production --confirm production
bash ./deploy/control status --env production --json

For prod-local, replace production with local. While copying, the controller stops application writes and image cleanup, then restores application operation. Stop your own background jobs and SQL writes separately.

Save the point ID from the output or lastBackup in status. null means status has no confirmed backup. Local points are in <backup.root>/<project>/<environment>/points/<point-id>/; for S3, check the selected prefix. There is currently no backup list command.

3. Restore a point

Restore returns data to the backup time: later records will be absent from the restored database. If you also need current data, save it in a separate point first.

bash ./deploy/control restore --env production \
  --recovery-point POINT_ID --confirm-restore production

bash ./deploy/control status --env production --json

Substitute a complete point ID. Restore uses --confirm-restore, rather than --confirm. The controller prepares a new database and media directory, checks them, and switches the application. Previous data is preserved. After startup, check records, images, and integrations before deleting anything.

If restore is interrupted, start with status/reconcile and operation recovery. Do not start another restore over an unfinished one.

What to preserve with a backup

A point includes PostgreSQL, media files and sizes, release information, checksums, and a completion marker. A partial point cannot be restored. Retention keeps seven daily and four weekly points by UTC, protects unfinished operations, and does not delete the last working backup because a new backup failed.

Preserve secrets, private keys, and SSH access separately — they are not included. Exact release images are also needed: Registry keeps them in the registry; Source/Archive keeps them in an image archive. Verified server archives live in <root>/image-archives; these are separate files, not part of the backup point.

Recovery on a new server

Prepare the server, environment profile, secrets, and backup access following deployment instructions. Keep the original project/environment values used to locate points. Supply the release and its images, run provision, then restore. Source needs a checkout on the VPS; Archive/Registry is managed over SSH.

This is the standard backup-point scenario. Importing a dev dump first requires a successful initial deploy. Do not create current/reservation files manually. Periodically verify restore in a separate environment: the presence of files alone does not confirm recoverability.