OwnStack

Stack backups

Stack backups capture every database (Postgres, MySQL, MongoDB, Redis snapshots) and every persistent volume on a stack, on whatever schedule you configure. Backups go to S3 or any S3-compatible object store you configure. Restore is point-in-time per database, per volume.

Configure

In the dashboard, Stack → Backups → Configure. Set:

FieldWhat to set
Destinations3://<bucket>/<prefix>/ — bucket should be in the same region as the stack.
EndpointFor S3-compatible providers (Backblaze B2, Cloudflare R2, MinIO), set the endpoint URL. Skip for AWS S3.
CredentialsAccess key + secret key with s3:PutObject, s3:GetObject, s3:DeleteObject, s3:ListBucket.
ScheduleCron expression. Daily 03:00 UTC (0 3 * * *) is a sensible default.
RetentionHow many backups to keep. Older ones are pruned automatically.
EncryptionOptional: server-side via S3, or client-side via a passphrase you supply.

Or via CLI:

$ ownstack stack backup config <stack>

Run a manual backup

$ ownstack stack backup run <stack>
Backup job 412 enqueued for stack <stack>.

$ ownstack stack backup list <stack>
  ID    STARTED              STATUS     SIZE     SERVICES
  412   2026-05-04 03:00:01  completed  4.2 GiB  postgres-app1, postgres-app2, mysql-app3, redis-app1

What a backup contains

ServiceFormat
Postgrespg_dump --format=custom per database, plus globals (pg_dumpall --globals-only).
MySQLmysqldump per database, gzipped.
MongoDBmongodump per database, archived.
RedisRDB snapshot.
Persistent volumestar + gzip per volume.

Restore

Restoration is per service, not stack-wide. Pick the backup, pick the database/volume to restore, and OwnStack writes it back into the running service:

$ ownstack db restore --app=<app> --backup=<backup-id>
$ ownstack db restore:info <ID> --follow

The restore happens on the stack via dokku postgres:import (or the matching MySQL/Mongo equivalent). The target service is restarted; the linked app picks up the restored data on its next request.

Restoring is destructive

The restore replaces the current data in the target service. There's no in-place merge. Snapshot the current state first if you might need it.

Scheduling notes

  • Backups run on the stack itself; they consume CPU and disk while running. Schedule for low-traffic windows.
  • Database dumps lock briefly (Postgres uses transaction-level snapshot, no exclusive lock; MySQL with InnoDB uses consistent snapshot via --single-transaction; Redis BGSAVE forks).
  • Volume tar runs fsfreeze if available — quiesces the filesystem for a consistent snapshot. Apps should handle a brief pause.

Off-site copies

If you want backups in a second region or a different provider, configure a second backup destination in the dashboard. OwnStack writes to all configured destinations on each scheduled run.