Backups and restore

The Backups tab on each database service lets you create internal backup files on the same machine that runs the database (through dFlow’s Dokku integration). That is ideal before migrations or risky schema changes, but it is not a full off-site disaster-recovery strategy by itself—if you lose the server, you can lose the dumps that were stored only there.

If you are new to databases in dFlow, read Databases overview first.

Open the Backups tab

1. Go to Applications → your application → Environment.

2. Open your database service (created with Add service → Database).

3. Click Backups.

The UI describes this area as the place to create and manage database backups.

What “internal backup” means

Internal backup writes a .dump file onto the server’s disk (same host as the database service). dFlow also stores a backup record in the platform so you can restore or delete from the dashboard.

Plain-language flow:

1. You click Create Backup → Internal Backup (wording in the UI: creates backup within the server).

2. dFlow inserts a backup row with status in-progress and enqueues work on the linked server.

3. Over SSH, a worker runs dFlow’s Dokku internal export helper. The database plugin performs the export and writes a file whose name includes your service name and a UTC timestamp, for example my-db-2026-04-08-14-30-00.dump.

4. When export succeeds, the record becomes success. If the job errors, check Logs / deployment streams on the server; the UI might still show in-progress if the worker cannot update status cleanly—treat long-running in-progress rows as a sign to investigate.

Compute requirement: backup jobs need a resolvable path to a self-managed server (servers) from the service’s project or from the environment compute when that compute is a server relation. If no server is linked, creation should fail; avoid orphan in-progress rows by ensuring compute is attached before relying on backups.

Backup status values

The dashboard shows the raw API status on each row:

Restore

Restore queues an import job. The worker reconstructs the dump filename from the backup timestamp and runs the Dokku internal import helper so data flows back into the live database service.

Warning: restore is destructive. It replaces current database contents with the backup snapshot. Take a fresh backup first if you are unsure, and coordinate with your team.

Implementation note: restore (and delete) resolve SSH from the service’s project and its linked server. If your database exists only under an unusual environment layout, confirm behavior in your workspace before you depend on restore in production.

Delete a backup

Delete removes the dump file from the server and soft-deletes the backup record in dFlow when the remote command succeeds.

Scheduled and external backups (not active yet)

In the Create Backup menu you may see:

• Configure backup schedule (daily / weekly / monthly copy in the UI)—Save schedule stays disabled with Coming soon text; scheduling is not active.

• External Backup (for example object storage)—also Coming soon / disabled.

Until those ship, plan separate tooling for automated and off-site retention (provider snapshots, pg_dump to object storage, and so on).

Permissions (typical keys)

Exact roles depend on your workspace, but server actions generally map roughly as follows:

Limitations you should know

• Legacy managed project type: creating a backup may be blocked (action returns Not allowed to create backup). Prefer current Applications flows on self-managed compute.

• Internal-only today: dumps remain on the server unless you copy them elsewhere.

• Expose / connection issues are covered in Database troubleshooting, not in this page.

Related

• Databases overview

• Database troubleshooting