Backups and restore

The Backups tab on each database service lets you choose where dumps are stored, run manual or scheduled backups, and restore or delete snapshots from the dashboard.

• Internal storage keeps .dump files on the Worker Node (fast local snapshots before risky changes).

• External storage uploads dumps to your S3-compatible bucket (off-server disaster recovery).

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 tab has three areas:

1. Backup destination — internal vs external storage (saved per database service).

2. Create backup schedule and Create backup — automation and one-off runs.

3. Backup list — each row shows timestamp, storage type, status, and actions.

Backup destination

Every manual and scheduled backup uses the destination you save on this tab.

Internal storage (default)

1. Under Backup destination, select Internal storage.

2. Click Save destination.

Dumps stay on the server disk. No Integrations setup is required.

External storage (S3-compatible)

1. Connect a bucket under Integrations → Backup Storage and ensure the provider shows status verified. See Backup storage integration.

2. On the Backups tab, select External storage.

3. Choose a verified provider from the dropdown (unverified accounts cannot be selected).

4. Click Save destination.

If no verified provider exists, the UI links to Open Backup Storage under Integrations.

External storage is required when you enable a backup schedule and this service’s destination is External storage. Internal schedules do not need Backup Storage.

After you change destination, the next Create backup or scheduled run uses the new setting. Existing backup rows keep their original type (internal or external).

Internal backups

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

Flow:

1. You click Create backup (or a schedule runs — see below).

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

3. Over SSH, a worker runs the Dokku internal export helper. The dump filename includes your service name and a UTC timestamp, for example my-db-2026-04-08-14-30-00-000.dump.

4. On success, the record becomes success. On failure, it becomes failed with an error message.

Compute requirement: backup jobs need a self-managed server (servers) resolved from the service’s project or environment compute. Attach compute before relying on backups; otherwise creation should fail instead of leaving orphan jobs.

External backups

External backups use the same on-server export step, then copy the dump to your bucket.

Flow:

1. dFlow creates an in-progress backup with type external.

2. The worker exports the database to a temporary file on the server over SSH.

3. The worker downloads that file and uploads it to your bucket with the Backup Storage credentials (S3-compatible API).

4. The temporary file on the server is removed after upload.

5. The backup record is updated with success, plus bucket, object key, and storage provider metadata for restore and delete.

Object keys look like {prefix}/{service-name}-{timestamp}.dump. The default prefix is dflow/backups (set on the storage provider at connect time). Your bucket policy must allow PutObject, GetObject, DeleteObject, and ListBucket for that prefix.

Restore downloads the object from the bucket, imports it into the live database over SSH, and cleans up temporary files.

Delete removes the object from the bucket (including versioned buckets such as Backblaze B2 when versioning is enabled) and soft-deletes the backup record in dFlow.

Manual Create backup and scheduled runs both follow this flow when External storage is saved on the tab.

Scheduled backups

Use Create backup schedule to turn on one or more tiers. You can enable multiple tiers at once (for example Daily and Weekly). Uncheck every tier and click Save schedule to disable automation.

After you save, the Backup destination card shows Active schedules: with the tier names you enabled.

Schedule tiers

The UI describes retention in plain language (for example “kept for 7 days” on Daily); the platform enforces the count in the table above. When a scheduled backup succeeds, older successful backups for that tier only are deleted automatically until the count fits the limit. Pruning applies to both internal and external backups.

How scheduling works

• A background check runs about every 10 minutes for all database services that have at least one tier enabled.

• For each enabled tier that is due (based on the tier’s interval and the last successful run time), dFlow queues one backup with trigger scheduled and the matching scheduleTier (hourly, daily, weekly, or monthly).

• If a backup is already in-progress for that service, the scheduler skips further tiers until it finishes (avoids overlapping exports).

• Saving a schedule triggers an immediate pass for due tiers so you do not have to wait for the next interval.

• Scheduled backups use the same backup destination (internal or external) as manual Create backup.

Reading the backup list

Scheduled rows may show extra badges:

Manual backup

Click Create backup to queue a single run with trigger manual. It uses the saved backup destination and the same internal or external flow as scheduled jobs.

Backup status values

Backups left in-progress for more than about two hours are marked failed automatically (stale job cleanup).

Restore

Click Restore on a success row. Restore is destructive: it replaces the live database with the snapshot.

• Internal: the worker imports the .dump file from the server disk.

• External: the worker downloads the object from your bucket, then imports it over SSH.

Take a fresh backup first if you are unsure. Restore and delete resolve SSH from the service’s project / environment compute; confirm compute is attached in unusual layouts before you depend on this in production.

Delete a backup

Click Delete on a row to queue removal:

• Internal: deletes the .dump on the server and soft-deletes the backup record when the remote command succeeds.

• External: deletes the object from the bucket (all versions when the provider supports it) and soft-deletes the record.

Scheduled retention may also delete older success backups for a tier without using the Delete button.

Permissions (typical keys)

Exact roles depend on your workspace:

Limitations you should know

• Legacy managed project type: backup creation may be blocked (Not allowed to create backup). Use current Applications on self-managed compute.

• External destination: requires a verified provider and Save destination before manual or scheduled external backups succeed.

• Internal destination: scheduled backups do not require Backup Storage; only External storage needs a verified integration.

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

Related

• Backup storage integration

• Databases overview

• Database troubleshooting

• Integration troubleshooting