Scheduled Database Backups

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.

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.

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

Open the one-shot backup form

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

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.

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.

Create a Schedule

Open backup settings

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

Choose connection and databases

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

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.

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.

Choose contents and retention

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

Save and verify

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

Table Patterns

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

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.

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.

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. 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	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