Database Backups

Backups are logical dumps of individual databases, taken on the server with each engine’s own tool, encrypted before they touch disk, and kept on the server, in off-server storage (S3-compatible or Google Drive), or both.

What a backup is

• Every file is encrypted with AES-256 using a key that the control plane generates once and keeps encrypted. The key reaches the server only through the job-secrets channel, never on a command line.
• A SHA-256 checksum is recorded for every file and checked before any restore.
• Local copies live in /var/lib/vpspilot-backups.
• Dumps are limited to three hours.

Schedules

Each database instance has its own policy:

PUT /api/v1/backups/policies/{instance_id}{ "enabled": true, "every_hours": 6, "keep": 28 }

The API’s background loop starts backups when they are due. If the control plane is down at that moment, the backup runs as soon as it is back.

Manual backups

Take one before a risky migration with Back up now, or through the API. Leave out database to back up every database in the policy.

POST /api/v1/backups/run{ "instance_id": "4d1e…", "database": "app" }

App file backups

Databases aren't the only thing worth keeping. The File Backups section of an app backs up what it keeps between deploys (see files that survive deploys): a Docker app's data folder, a systemd app's shared folder, or a Compose project's named volumes.

• One encrypted .tar.gz.enc per backup (AES-256, the same key as database backups), stored and uploaded the same way.
• Schedules, retention, Back up now and off-server storage work as for databases.
• Verify decrypts the backup and reads every file. Restore stops the app, empties the folder or volumes, puts the files back and starts it again.
• Files are copied as they are: a database running inside a Compose project should be backed up as a database, not from its volume.

PUT  /api/v1/backups/apps/{app_id}/policy   { "enabled": true, "every_hours": 24, "keep": 7 }POST /api/v1/backups/apps/{app_id}/run

Needs agent 1.1.4 or later.

Staleness alerts

The Backups stale or failing alert rule fires as soon as a scheduled backup fails, or when a database or app has had no successful backup for 36 hours. Adjust the threshold in Monitoring.