MariaDB Backups
mariadb-dump vs mydumper / myloader: which logical dump tool should you use?
Both produce a logical SQL dump. The difference lies in parallelism, partial restores and how long it takes to bring a database back online. Here's when to stick with mariadb-dump and when to move to mydumper / myloader.
Logical dump or physical backup: framing the question
For production backups of a large database, the answer is often neither: a physical backup with mariabackup restores much faster than a SQL dump. We cover that choice in mysqldump vs mariabackup: real restore times.
A logical dump often becomes the right tool again when you need to change engine, hosting provider or jump several versions: migrating MySQL to MariaDB, leaving AWS RDS where physical backups are out of reach, rebuilding a database cleanly during an upgrade (which can also be done in place). That's where the choice between mariadb-dump and mydumper matters.
mariadb-dump or mysqldump: it's the same tool
Since MariaDB 10.5, the tool is called mariadb-dump, and mysqldump is just a compatibility alias, deprecated since MariaDB 11.0 and missing from some installs (the official Docker image, for instance). Options are identical: use the mariadb-dump name in your scripts.
Don't confuse it with MySQL 8's mysqldump, which is a different binary. Run against a MariaDB server, it can fail on MySQL-specific queries (typically column statistics, disabled with --column-statistics=0). Simple rule: dump a MariaDB server with the MariaDB client.
mariadb-dump: simple, already there, sequential
mariadb-dump reads tables one at a time and writes a SQL stream (CREATE TABLE then INSERT). With --single-transaction, it opens a consistent InnoDB transaction without blocking writes during the export.
Its strengths: it ships with the MariaDB client tools, usually installed with the server, and the resulting file is readable SQL, easy to replay or inspect. For a schema-only dump (--no-data), a one-off export or a database of a few GB, there's no reason to look further.
Its limit: with a classic SQL dump, everything is sequential, on export and on restore. The client replays the file over a single connection, table after table, index after index, even on a 16-core server. And to recover one table from a 200 GB file, the safest route is restoring the dump on a separate instance and re-exporting that table. Since MariaDB 11.4 and 11.5, --parallel with --tab or --dir exports several tables at once, reloaded with mariadb-import --parallel (and --dir since 11.6): a different format (SQL definitions plus tab-separated data) from the single SQL file.
mydumper / myloader: parallel logical dumps
mydumper is an open source project that exports several tables at once, with one thread per table or per table chunk. In its default mode, it takes a global lock, opens a consistent transactional snapshot shared by all its threads, then releases the lock: with InnoDB-only data the lock is brief (but it waits for long-running queries to finish, blocking writes meanwhile) and the export carries on without blocking the application. Non-transactional tables (MyISAM, Aria) hold it while they are exported.
The result is a directory: a schema file and one or more data files per table, plus a metadata file holding the binlog position and GTID at snapshot time, when binlogs are enabled on the source. Large tables are split into chunks (--rows), so they can be reloaded in parallel.
myloader does the reverse, with multiple threads. Recent versions can create tables without their secondary indexes, load the data, then add the indexes at the end (--optimize-keys): on heavily indexed databases, that's often where the biggest gain lies, to be measured on your data.
The trade-offs: it's a package to install (distro packages are often several releases behind GitHub), the format (SQL files) can in theory be reloaded by hand, but myloader is what handles order and dependencies, and the gain depends on the database's shape. A database dominated by one giant table, without chunking, stays bound by that table.
Side-by-side comparison
Same family of tools (logical SQL dump), different jobs.
| Criterion | mariadb-dump | mydumper / myloader |
|---|---|---|
| Parallelism (dump) | Sequential for a SQL dump; parallel only with --tab / --dir (--parallel, MariaDB 11.4+ / 11.5+) | Multi-threaded, one thread per table or chunk |
| Parallelism (restore) | One connection (mariadb < dump.sql); mariadb-import --parallel for --tab / --dir output | Multi-threaded with myloader |
| Output | One SQL file (or --tab per table) | A directory: one schema file + data files per table, plus a metadata file |
| Consistency | --single-transaction (InnoDB) | Global lock (short with InnoDB-only data), then one consistent snapshot shared by every thread |
| Large tables | Dumped in one go | Split into chunks (--rows), restored in parallel |
| Restoring a single table | Extract it from the file (sed/awk) or dump again | Native: pick the table's files |
| Replication coordinates | --master-data / --gtid in the dump header | Binlog position / GTID in the metadata file, when binlogs are enabled |
| Availability | Part of the MariaDB client tools, usually installed with the server | Separate package, distro versions often lag upstream |
| Portability of the result | Plain SQL, but recent dumps start with a sandbox line that older clients and the MySQL client reject | SQL files too, but myloader handles the order and dependencies |
| Best for | Small databases, one-off exports, schema-only dumps | Logical dumps of tens to hundreds of GB, migrations where physical backup is impossible |
The basic commands
Minimal examples to adapt (credentials, databases, compression). Check which options your mydumper version supports.
mariadb-dump: full export (consistent for InnoDB), with replication coordinates
mariadb-dump --single-transaction --routines --events \
--master-data=2 --gtid --all-databases \
| zstd -T0 > full-$(date +%F).sql.zstmydumper: parallel export on 8 threads, large tables chunked
mydumper --threads 8 --rows 500000 --compress \
--routines --events --triggers \
--outputdir /backup/dump-$(date +%F)myloader: parallel restore
# --drop-table: recent versions / --overwrite-tables: older ones
myloader --threads 8 --drop-table --optimize-keys \
--directory /backup/dump-2026-09-28Which tool for which situation?
A few GB, one-off export or copy
mariadb-dump. Nothing to install, one readable SQL file.
Schema-only dump, structure review or diff
mariadb-dump --no-data.
Major version upgrade on a database of tens of GB
mydumper / myloader. Parallel restore shortens the cutover window.
Leaving AWS RDS or a DBaaS without file access
mydumper / myloader, followed by replication to catch up before cutover.
Restoring a table dropped by mistake
mydumper, if your dumps are made with it: reload only that table.
Production backup of a large database
Neither first: mariabackup, with a logical dump as a complement.
Common pitfalls
- Forgetting routines, events and triggers:
--routines --eventson the mariadb-dump side, equivalent options on the mydumper side. If the application relies on stored procedures, a dump without them won't bring it back. - Restoring a recent MariaDB dump with an old client or MySQL's
mysqlclient: the first line ("sandbox" mode) makes them fail. Restore with an up-to-datemariadbclient, or strip that line knowingly. - Using
--single-transactionwith MyISAM or Aria tables: they're not covered by the snapshot and may be inconsistent. - Running DDL (
ALTER TABLE) during the dump: it breaks consistency or blocks the export. - Dumping the primary under full load: use a replica when you have one.
- Never testing the restore. A dump that has never been reloaded is not a backup.
What we do at RDEM Systems
On the servers we manage, backups combine ZFS snapshots, a VM backup to Proxmox Backup Server and a daily SQL dump (mysqldump / mariadb-dump) driven by Signal18 Replication Manager: that dump is the portable safety net, restorable on any compatible server. Details on our MariaDB backups page.
For a large migration (MySQL to MariaDB, leaving AWS RDS), mydumper / myloader is what we recommend, with one simple rule: measure the actual load time on a copy before setting the cutover window, rather than estimating it.
Frequently asked questions
What's the difference between mariadb-dump and mysqldump?
On MariaDB, none: since MariaDB 10.5, mysqldump is an alias of mariadb-dump, deprecated since 11.0 and missing from some installs. The mysqldump shipped with MySQL 8 is a different binary, which can fail against a MariaDB server (column statistics in particular).
Does mydumper work with MariaDB?
Yes, mydumper and myloader work with MariaDB as well as MySQL. Use a recent version from the GitHub releases: distro packages are often old.
Does mydumper replace mariabackup?
No. mydumper is still a logical dump: restoring replays SQL and rebuilds indexes. To restore a large production database quickly, a physical backup (mariabackup) remains faster. mydumper is for when you need a portable format.
How many threads should mydumper and myloader use?
A practical starting point is the number of available cores, while watching disk I/O and load on the source server. Then tune by measuring: when a few tables hold most of the data, extra threads add little without chunking (--rows).
A migration or major upgrade to prepare?
We measure actual dump and restore times on a copy of your database before setting the cutover window.
Start your managed MariaDB project
Let's discuss your database needs. Our DBA team advises you on the optimal architecture for your use case.
RDEM Systems SAS — SIREN 820 338 671 — 5 B rue des Noyers, 95300 Pontoise