191 lines
10 KiB
Plaintext
191 lines
10 KiB
Plaintext
---
|
|
title: Scheduled Database Backups
|
|
description: Create manual, hourly, daily, or weekly SQL backup schedules for MySQL, PostgreSQL, and openGauss in DBX Desktop.
|
|
---
|
|
|
|
Scheduled database backups use the DBX database-export engine to generate SQL files for MySQL, PostgreSQL, and openGauss 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, PostgreSQL, and openGauss |
|
|
| Platform | DBX Desktop |
|
|
| Output | The default template creates one directory per scheduled run, containing one file per database/schema target; directory and file-name templates can be customized |
|
|
| Format | Plain SQL (`.sql`) and gzip-compressed SQL (`.sql.gz`) for every supported database; a Navicat backup archive (`.nb3`) for MySQL and PostgreSQL only |
|
|
| 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, PostgreSQL, or openGauss connection, destination directory, database scope, table scope, and backup contents. A one-shot backup has no schedule name, frequency, retention, or enabled state.
|
|
|
|
You can tick several connections in the connection list to back them all up in one go; each connection becomes its own run in **Backup history** and the runs execute one after another. With more than one connection, every connection backs up all of its databases, exact table selection is unavailable, and the file name template must contain `{runId}` so files from different connections never collide.
|
|
|
|
</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, PostgreSQL, or openGauss 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`, `.sql.gz`, and `.nb3` 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.
|
|
|
|
## Backups Created Outside DBX
|
|
|
|
The backup page also works with `.sql`, `.sql.gz`, and `.nb3` files that DBX did not create, such as Navicat backups:
|
|
|
|
- **Restore from file** picks any backup file and opens it in SQL File Execution. Nothing is added to the history.
|
|
- **Import backup** (DBX Desktop) adds one or more files to **Backup history**, labelled **Imported**, so they can be restored later with **Restore**. A Navicat `.nb3` entry shows its source database and schema and the time the backup was taken.
|
|
|
|
DBX never deletes imported files. Deleting an imported entry only removes it from the history, and retention never applies to imported entries. The same file cannot be imported twice.
|
|
|
|
## Navicat Backups (.nb3)
|
|
|
|
Choose **Navicat backup (.nb3)** as the backup format on a MySQL or PostgreSQL connection to write the archive layout Navicat uses: a tar archive with a `meta.json` index, gzipped per-object metadata (DDL, indexes, constraints, triggers), and gzipped row chunks, each protected by a SHA-1 checksum. The format is not offered for other database types.
|
|
|
|
DBX also restores `.nb3` files, including archives created by Navicat. Open the file in [SQL File Execution](/en/docs/sql-file) or click **Restore** in backup history. DBX turns the archive into a restore script that:
|
|
|
|
1. Drops the archived tables, views, and sequences (`DROP ... IF EXISTS`; PostgreSQL uses `CASCADE`)
|
|
2. Creates sequences, routines, and tables, then loads the rows in batched `INSERT` statements
|
|
3. Adds indexes, constraints, sequence values, views, and triggers
|
|
|
|
<Callout type="warn">Restoring an `.nb3` file replaces the archived objects in the destination. Restore into an empty or disposable database first. Encrypted Navicat backups are not supported, and an archive can only be restored into the same database engine that produced it.</Callout>
|
|
|
|
## 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>
|