dbx/docs/content/docs/database-backup.mdx

---
title: Scheduled Database Backups
description: Create manual, hourly, daily, or weekly SQL backup schedules for MySQL and PostgreSQL in DBX Desktop.
---

Scheduled database backups use the DBX database-export engine to generate SQL files for MySQL and PostgreSQL connections. They are useful for recurring logical backups of development, test, and small or medium databases and include table scope, retention, run history, and manual execution.

For a backup that should run only once, use **Back up now** in Settings instead of creating a schedule. Configure the same connection, destination, database, table, and content scope, then choose **Start backup**. This one-shot run does not create or change a schedule, does not calculate a next run, and appears in the same backup history as scheduled runs.

<Callout type="warn">Scheduled backups currently require DBX Desktop to remain running. They are not an independent server scheduler and do not replace physical backups, point-in-time recovery, WAL/binlog archiving, or cloud-provider backup services.</Callout>

## Support Scope

| Item | Current behavior |
| --- | --- |
| Databases | MySQL and PostgreSQL |
| Platform | DBX Desktop |
| Output | The default template creates one directory per scheduled run, containing one `.sql` file per database/schema target; directory and file-name templates can be customized |
| Frequency | Every N hours, daily at a time, or weekly on a weekday and time |
| Contents | Table structure, data, database objects, and optional `DROP TABLE IF EXISTS` |
| Table scope | All, include by pattern, or exclude by pattern |
| Retention | Keep a configured number of recent successful backup files |

## Run a One-time Backup

<Steps>
  <Step>
    ### Open the one-shot backup form

    Open the database backup page in Settings and choose **Back up now**.

  </Step>
  <Step>
    ### Configure the backup

    Select a MySQL or PostgreSQL connection, destination directory, database scope, table scope, and backup contents. A one-shot backup has no schedule name, frequency, retention, or enabled state.

  </Step>
  <Step>
    ### Start and verify

    Choose **Start backup**. The run uses the shared database-export engine and appears in **Backup history**, where progress, cancellation, generated files, and errors use the same behavior as scheduled runs.

  </Step>
</Steps>

## Create a Schedule

<Steps>
  <Step>
    ### Open backup settings

    Open the database backup page in Settings and create a schedule.

  </Step>
  <Step>
    ### Choose connection and databases

    Select a MySQL or PostgreSQL connection. Back up all non-system databases or choose specific databases.

  </Step>
  <Step>
    ### Configure table scope

    Choose all tables, include matching patterns, or exclude matching patterns. Patterns support `*` and `?` and can match `schema.table` or `database.schema.table`.

  </Step>
  <Step>
    ### Set directory and frequency

    Select a local destination directory and configure the output path template, which combines a relative run-directory template with a file-name template. Directory templates support `{schedule}`, `{date}`, `{timestamp}`, and `{runId}`. File-name templates also support `{database}`. DBX previews the complete output path and automatically adds a missing database target. A run ID is included only when `{runId}` is explicitly present in the template; if a template resolves to a path already used by another run, DBX rejects the new run instead of overwriting the existing backup.

  </Step>
  <Step>
    ### Choose contents and retention

    Select structure, data, objects, and `DROP TABLE IF EXISTS`, then choose how many historical backups to retain.

  </Step>
  <Step>
    ### Save and verify

    Run the schedule manually first. Verify connection permissions, table scope, destination directory, and generated files before enabling automatic execution.

  </Step>
</Steps>

## Table Patterns

Separate patterns with commas, semicolons, or newlines. For example:

```text
public.*
audit_*
orders_202?
```

- **Include** exports only matching tables
- **Exclude** exports everything else and skips matching tables
- PostgreSQL names are case-sensitive
- MySQL matching follows `lower_case_table_names`

If an include rule matches no tables, the run fails instead of reporting an empty successful backup.

## Consistency and Execution

Each backup establishes a consistent snapshot session before exporting database/schema targets. DBX rolls back the read-only snapshot transaction afterward and does not commit business changes.

Backup runs appear in the shared export task area and show:

- Current database and object
- Success, failure, or cancelled status
- Manual or scheduled trigger
- Generated file list
- Error details and timestamps

Cancellation stops remaining exports. On failure or cancellation, DBX attempts to remove partial files from the run so incomplete output is not mistaken for a successful backup.

## Retention and History

Each schedule has a retention count. Older runs beyond the limit are pruned from history and their files are deleted. The default run directory includes a unique run ID, while directory templates can be customized to fit your workflow. Individual backup runs and files can also be removed manually.

<Callout type="warn">The destination directory still needs independent OS, NAS, or object-storage backup. Saving to another folder on the same disk does not protect against disk failure, ransomware, or loss of the machine.</Callout>

## Restore Drills

For MySQL-compatible connections, restore individual tables from a single `.sql` or `.sql.gz` backup. Expand a backup's file list, click **Restore**, then choose **Selected tables** under **Restore scope**. Once the full file has been scanned, search and select the tables to restore. Tables do not need to exist in the destination, and identically named tables in different source databases are listed separately.

Selected-table mode restores table structure, indexes, and data, excluding views, routines, triggers, and events. Database context in the dump still applies; tables without an explicit database use the destination chosen in the dialog. Existing foreign keys or triggers can affect the restore. Choose **All contents** for a complete restore. Statements whose scope cannot be determined cause selective restore to fail before execution.

Generated `.sql` files can be imported through [SQL File Execution](/en/docs/sql-file). Regularly verify in an isolated environment that:

- The complete file can be read and executed
- Schema, indexes, objects, and row counts are correct
- Charset, timezone, sequence/identity values, and privileges have any required follow-up steps
- The application can connect to the restored database

A successful backup run means file generation completed; it does not prove restore readiness.

## Scheduled Backup vs. Database Export

| Feature | Best for |
| --- | --- |
| [Database Export](/en/docs/database-export) | One-time migration, pre-change backup, and manual scope selection |
| Scheduled Database Backup | Recurring logical backups for a fixed connection and scope |
| Native database backup | Large production databases, PITR, incremental/physical backup, HA, and compliance requirements |

## Safety Guidance

- Use a database account with only the read privileges required for backup
- Protect and encrypt the destination according to the data sensitivity level
- Never commit SQL files containing business data to a public repository
- Recheck scope after databases or tables are renamed
- If DBX Desktop is closed, the computer sleeps, or the destination is unavailable, schedules do not run with server-scheduler reliability

<Cards>
  <Card title="One-time database export" href="/en/docs/database-export">
    Manually choose structure, data, objects, and database scope.
  </Card>
  <Card title="Restore SQL files" href="/en/docs/sql-file">
    Execute backup files with statement-level progress and errors.
  </Card>
  <Card title="Production safety" href="/en/docs/production-safety">
    Use read-only accounts, production protection, and least-privilege policies.
  </Card>
</Cards>