If you run MariaDB or MySQL in production, you have two built-in backup utilities sitting right on the server: mysqldump (the logical SQL dumper, now also called mariadb-dump since MariaDB 11.0) and mariabackup (the physical hot-backup tool, also known as mariadb-backup). Picking the right one for your database size, workload, and recovery target is one of the most common sources of backup pain — and one of the easiest to fix once you understand how each tool actually moves data.
This guide is the mysqldump vs mariabackup comparison I wish I had five years ago. We will look at how each tool works under the hood, benchmark both on real-world database sizes, walk through the restore workflows side by side, and finish with a decision matrix so you can pick the right tool for your environment in 2026.
Table of Contents
mysqldump vs mariabackup at a glance
The fastest way to feel the difference is one table. If you read nothing else, read this.
| Dimension | mysqldump / mariadb-dump | mariabackup / mariadb-backup |
|---|---|---|
| Backup type | Logical — text file of SQL statements | Physical — binary copy of InnoDB data files |
| Hot or cold | Hot with --single-transaction (InnoDB only); warm with --lock-tables | True hot online backup for InnoDB / Aria / MyISAM |
| Locks taken | MDL on every table when --lock-tables; metadata lock for snapshot only with --single-transaction | No blocking locks for InnoDB; brief lock for non-InnoDB engines at the end |
| Typical backup speed (100 GB InnoDB) | 45 to 90 minutes | 5 to 15 minutes |
| Typical restore speed (100 GB InnoDB) | Several hours (INSERT replay + index rebuild) | 10 to 30 minutes (file copy + crash recovery) |
| Backup size | Usually larger (SQL text, no InnoDB page compression) | Usually smaller (raw files, supports --compress with zstd) |
| Incremental backups | Not natively; rely on binlog replay | Yes, LSN-based via --incremental-basedir |
| Point-in-time recovery (PITR) | Yes via --master-data + binlog replay | Yes via xtrabackup_binlog_info + binlog replay |
| Cross-version portability | Excellent — SQL text works across MariaDB and MySQL major versions | Restricted — binary version must match the source server’s major.minor |
| Encryption at rest | External tooling (gpg, openssl) | Built-in AES-256 with --encrypt |
| Galera SST | Possible but slow (mysqldump SST) | Recommended method for clusters above a few GB |
That single table answers most of the mysqldump vs mariabackup questions engineers ask on Reddit and the MariaDB Knowledge Base. The rest of this guide unpacks why those rows look the way they do.
What is mysqldump (mariadb-dump) and how does it work?
mysqldump is a client-side utility that ships with every MariaDB and MySQL distribution. It connects to the server like any other application, asks the server to describe every table, then writes a text file of SQL statements that recreate that schema and load the data. On MariaDB 11.0 and later the binary is a thin wrapper around mariadb-dump — running mysqldump on a fresh MariaDB 11.x server actually invokes mariadb-dump internally.
The output is plain text. It contains CREATE TABLE statements for the schema, INSERT statements for the rows, and — if you pass the right flags — stored routines, triggers, events, and the current binary log coordinates. Because it is plain SQL, you can read it, grep it, edit it, version-control it, and feed it into any MySQL- or MariaDB-compatible client on any platform.
How consistency works inside mysqldump
Two flags govern how mysqldump keeps its output consistent against a live server.
The first is --single-transaction, which is the single most important flag in the tool. It issues START TRANSACTION WITH CONSISTENT SNAPSHOT at the start of the dump. Inside that REPEATABLE READ transaction, every subsequent SELECT sees the same snapshot of the database, so the dump is consistent even while other clients write to the server. This flag works for InnoDB and Aria; it does not protect MyISAM or MyRocks tables because those engines do not participate in MVCC transactions.
The second is --lock-all-tables (or its alias -x), which acquires a global read lock for the duration of the dump. The dump is consistent across every storage engine, but every write to every table is blocked until mysqldump finishes. On a busy server this is the flag that causes the dreaded “Table definition has changed, please retry transaction” errors in the application logs.
Row-by-row output and memory pressure
By default mysqldump fetches every row into memory before writing the INSERT block. On a table with millions of rows that turns into a multi-gigabyte allocation and a slow scan. The fix is --quick, which forces row-by-row retrieval so the dump streams instead of buffering. Almost every production wrapper script adds --quick — without it, large tables dump painfully slowly and can OOM the client.
The companion flag --extended-insert groups many rows into a single multi-row INSERT statement. It cuts the dump file size and speeds up restore dramatically, at the cost of an unreadable text file. Most teams treat both flags as non-optional in 2026.
What is mariabackup (mariadb-backup) and how does it work?
mariabackup — renamed to mariadb-backup in MariaDB 11.0 — is a physical, hot-backup utility that ships with every MariaDB 10.1.23+ server. It started as a fork of Percona XtraBackup 2.3.8 and has since diverged to add MariaDB-specific features: Data-at-Rest Encryption support, InnoDB Page Compression awareness, MyRocks backup, Galera SST integration, and a few extended options.
Instead of asking the server to describe and re-emit every row, mariabackup copies the InnoDB data files directly from the server’s data directory while the server is running. While it copies, it records the InnoDB redo log position at the start and end of the copy. The copy itself is not consistent — pages from different points in time are mixed together — but the redo log carries enough information to reconstruct any in-flight transaction.
The two-phase prepare-and-restore workflow
That is why mariabackup has a second phase called prepare. After the initial backup completes, you run mariadb-backup --prepare --target-dir=/backups/full. The prepare step replays the captured InnoDB redo log against the copied data files so the snapshot becomes crash-consistent. Only after prepare is the backup safe to restore.
Restore itself is the third phase. You point mariadb-backup --copy-back --target-dir=/backups/full at the prepared backup and it copies the files back into the server’s datadir. Because the prepared backup is essentially a functional datadir, you can also skip the tool entirely and just rsync the files into place — a trick that comes in handy when you need to restore a multi-terabyte database to a fresh server.
Why InnoDB is special in mariabackup
InnoDB is designed for crash recovery. The InnoDB redo log is a circular buffer of every change made to InnoDB tablespaces since the last checkpoint, and the engine knows how to replay that buffer on startup. mariabackup leans on this exact mechanism. The hot copy captures a mix of older and newer pages; the prepare step replays the redo log to bring the pages forward to a single consistent point in time. The result is a snapshot that looks identical to a server that crashed cleanly and was just restarted.
For MyISAM and Aria, mariabackup cannot avoid locks because those engines have no redo log to replay. The tool briefly locks each non-InnoDB table at the end of the backup to flush its contents — a few seconds per table, usually invisible in production.
mysqldump vs mariabackup: head-to-head comparison
Here is the same comparison table, expanded to cover the dimensions that matter for production operations. Use it when you are explaining the mysqldump vs mariabackup tradeoff to a teammate.
| Capability | mysqldump | mariabackup |
|---|---|---|
| Backup output | Single SQL file or directory of tab-separated files | Directory of binary files matching the datadir layout |
| Partial / table-level restore | Easy — sed or grep the SQL file | Possible with --export for individual tables, otherwise full restore |
| Compression | External — pipe through gzip, pigz, zstd | Built-in --compress with zstd; xbstream for streaming |
| Encryption | External — gpg or openssl after the dump | Built-in --encrypt with AES-256 |
| Parallelism | Single-threaded by default; --parallel in MariaDB 11.4.1+ for --tab dumps | Multi-threaded file copy and --compress-threads |
| Streaming to S3 | Easy — pipe stdout to aws s3 cp | Supported via xbstream + aws CLI, or mariabackup-internal streaming |
| CI / test data seeding | Perfect — small SQL loads quickly | Awkward — full restore overhead for tiny databases |
| Accidental DROP recovery | Easy if you kept the SQL file | Possible but requires a prepare + copy-back cycle |
| Cross-version migration | Ideal — SQL text is portable | Restricted — keep old binary for old-version restores |
| Required privileges | SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, RELOAD, plus process | RELOAD, PROCESS, LOCK TABLES, plus file system access to datadir |
Performance: backup and restore speed on real-world database sizes
The numbers most engineers care about are wall-clock time. Both MariaDB’s Knowledge Base and Severalnines have published benchmark ranges, and they tell a consistent story.
Backup time on InnoDB workloads
On a 100 GB InnoDB database with default settings, mysqldump takes roughly 45 to 90 minutes. The bottleneck is the server-side SELECT scan plus the client-side text formatting. mariabackup completes the same backup in 5 to 15 minutes because it is doing a sequential file copy plus a small redo log tail capture, with optional parallelism. The gap widens as the database grows: on a 500 GB database the mysqldump run can stretch past six hours, while mariabackup finishes in under an hour on hardware with local NVMe.
The MariaDB Knowledge Base documents these ranges and the Severalnines benchmark posts confirm them on production-shaped data. Percona’s own XtraBackup comparison posts put the physical-vs-logical gap at 5x to 10x for backup time and 10x to 20x for restore time.
Restore time is where mariabackup really wins
Backup is only half the story. The reason backups matter is restore, and on restore the gap is even larger. A mysqldump restore on a 100 GB database reads the SQL file, parses every statement, executes every CREATE and every multi-row INSERT, then rebuilds secondary indexes. Expect 2 to 4 hours. A mariabackup restore on the same database is a file copy followed by InnoDB crash recovery, which finishes in 10 to 30 minutes because InnoDB is highly optimized for that exact path.
This is the operational reason teams switch. RTO (recovery time objective) dominates the conversation once the database is over a few tens of gigabytes, and mariabackup’s restore curve is fundamentally flatter than mysqldump’s.
Locking and consistency behavior during backup
Consistency and locking are the other operational headache in the mysqldump vs mariabackup decision. Here is what each tool actually does to a running server.
mysqldump locking behavior
With --single-transaction, mysqldump takes a metadata lock for the duration of the dump. The MDL is per-table and lasts only as long as mysqldump is reading that table, but it blocks DDL (ALTER TABLE, DROP TABLE, RENAME TABLE) on every table in the dump. On a busy server you will see application threads queued behind the dump in SHOW PROCESSLIST.
Without --single-transaction, you must use --lock-all-tables to get a consistent dump, and that flag acquires a global read lock for the entire dump. Every write blocks. Long dumps become a maintenance window.
mariabackup locking behavior
For InnoDB tables, mariabackup takes essentially no locks during the bulk copy. It uses the InnoDB redo log to make the snapshot consistent. At the very end of the backup it briefly acquires locks on any non-InnoDB tables (MyISAM, Aria, MEMORY) to flush them; this is typically a few seconds and is invisible unless you have thousands of non-InnoDB tables.
The practical impact is that production write traffic continues uninterrupted during a mariabackup. This is the single biggest operational advantage on a busy production server in 2026.
Restore workflows: one-step SQL replay vs two-phase prepare and copy-back
The restore path is where the two tools feel most different. Here is a side-by-side example for a full server restore on MariaDB 11.x.
Restoring a mysqldump file
A mysqldump restore is one command. You pipe the SQL file into the client and let it execute.
mariadb < /backups/mysqldump/full-backup-2026-09-01.sql
That is the entire restore. The client parses each statement, executes it, and you are done. For cross-version restores you usually want to point the client at the same major version the dump was taken on, but a mysqldump from MariaDB 10.6 will load into MariaDB 11.x in almost every realistic case. A mysqldump from MariaDB 11.0+ that contains the sandbox-mode header can be imported into MariaDB 10.x or MySQL 8.0 by stripping the first few /*M!999999-- ... */ comments.
Restoring a mariabackup
A mariabackup restore is three steps. First prepare, then copy back, then start the server.
mariadb-backup --prepare --target-dir=/backups/mariabackup/full-2026-09-01
mariadb-backup --copy-back --target-dir=/backups/mariabackup/full-2026-09-01 --datadir=/var/lib/mysql
systemctl start mariadb
The prepare step is what most newcomers miss. Skipping it leaves you with a half-applied redo log and a datadir that InnoDB will refuse to start. Severalnines publishes a postmortem from a customer who lost 11 days of recovery time because a scripted restore skipped the prepare step on a 6-week-stale NAS backup.
The PITR bridge between the two tools
The two tools are not actually competitors for every workload — they cooperate. Both produce a binary log position file: mysqldump --master-data=2 writes a CHANGE MASTER TO comment in the dump; mariabackup writes xtrabackup_binlog_info in the backup directory. That file is the bridge from a full backup to point-in-time recovery: load the full backup, then replay the binary log from the recorded position forward to any timestamp you need.
Storage engine support and privileges required
The other dimension in the mysqldump vs mariabackup decision is which engines you are actually running.
Storage engine support matrix
| Engine | mysqldump | mariabackup |
|---|---|---|
| InnoDB | Full, atomic with --single-transaction | Full, hot online backup |
| Aria | Full, atomic with --single-transaction | Full, hot online backup |
| MyISAM | Consistent only with --lock-tables | Full, with brief lock at end of backup |
| MyRocks | Supported, consistent only with --lock-tables | Full hot backup (MariaDB-specific feature) |
| MEMORY | Schema dumped, data is not persistent | Skipped (in-memory data is not backed up) |
| CONNECT | Schema only; data sourced from external file at restore | Limited; external tables may need post-restore setup |
Privileges required for each tool
mysqldump needs SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, RELOAD, and PROCESS on the dumped databases. The actual grant is usually GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, RELOAD, PROCESS ON *.* TO 'backup'@'localhost'.
mariabackup needs RELOAD, PROCESS, LOCK TABLES, plus read access to the server’s datadir on disk. Because it copies data files, it normally runs as a local OS user (often mysql) that can read the datadir. S3 streaming and remote backups add their own network and credential requirements.
Compression, encryption, and streaming options compared
Compression and encryption are where the two tools diverge most sharply in 2026.
mysqldump outputs uncompressed SQL by default. The standard wrapper is to pipe the output through gzip, pigz, or zstd. The Reddit consensus on modern multi-core boxes is pigz -9 or zstd -3; plain gzip is single-threaded and noticeably slower on databases over a few hundred gigabytes. Encryption is layered externally: pipe the dump through gpg --symmetric --cipher-algo AES256 or openssl enc -aes-256-gcm -salt. The key handling then becomes your problem.
mariabackup has compression built in. --compress uses zstd, and --compress-threads=N parallelizes the work. For streaming, the --stream=xbstream mode produces a single stream that includes all metadata files in the right order, which you can pipe directly to xbstream -x on restore. Encryption is also built in: --encrypt=AES256 with --encrypt-key or --encrypt-key-file writes an encrypted backup. The repeated complaint on r/mariadb is that operators store the key on the same disk as the backup, which defeats the purpose — keep the key in a secret manager or a separate offline location.
Which tool should I use? Decision matrix and checklist
Five questions separate the right answer from the wrong one in the mysqldump vs mariabackup debate. Walk through them in order.
Decision checklist
- How big is the database? Under 10 GB: mysqldump is fine. 10 to 100 GB: mariabackup, or you will wait hours on restore. Over 100 GB: mariabackup is mandatory if you care about RTO.
- What is your RTO? Under one hour: mariabackup. Hours acceptable: either tool, but mariabackup is still faster.
- Do you need point-in-time recovery? Yes: both tools support it, but mariabackup’s incremental chains make daily PITR cheaper.
- Are you migrating across major versions or between MariaDB and MySQL? Yes: mysqldump wins because the SQL text is portable.
- Is the server in a Galera cluster? Yes: mariabackup is the recommended SST method above a few GB.
When to use mysqldump
mysqldump is the right tool for small databases (under 10 GB), for development and CI seeding, for cross-version migrations where SQL portability matters more than speed, and for capturing schema-only snapshots for code review. It is also the right tool when you need to grep, edit, or partial-restore a single table from a backup without bringing up an entire datadir.
When to use mariabackup
mariabackup is the right tool for any production MariaDB server over 10 GB, for Galera SSTs, for environments where RTO is measured in minutes rather than hours, for incremental backup chains to control storage growth, and for encrypted backups without layering external tooling.
Decision matrix by database size
| Database size | Recommended primary | Why |
|---|---|---|
| Under 10 GB | mysqldump | Simple, portable, fast enough, no binary-version coupling |
| 10 to 100 GB | mariabackup | Restore time dominates; physical backup is 10x faster |
| 100 GB to 1 TB | mariabackup with incrementals | Full backups become too costly without incrementals |
| Over 1 TB | mariabackup with streaming to object storage | Local disk cannot hold full backups; xbstream to S3 |
| Galera cluster, any size | mariabackup SST | Lock-free, fast, designed for the role |
| Cross-version migration | mysqldump | SQL text portable across MariaDB and MySQL major versions |
Hybrid strategy: using mariabackup and mysqldump together
The real production best practice — and the one no scraped competitor publishes — is to run both tools together. They are not actually competitors; they cover complementary failure modes.
The hybrid strategy is straightforward. Run mariabackup nightly as your fast-restore primary, with incremental backups every 6 hours if your write volume justifies the storage. Run mysqldump weekly as a portable, version-independent archive — ideally piped through zstd and shipped off-site immediately. Ship binary logs continuously to give you point-in-time recovery between the mariabackup snapshots. The mariabackup full backup gives you a 10-minute restore to the most recent nightly; the mysqldump gives you a portable fallback if a mariabackup file ever corrupts; the binlog gives you PITR to any second in the retention window.
Reddit and the MariaDB Knowledge Base both surface this pattern as the de facto production setup. The mariabackup file protects you against disk failure and accidental DROP; the mysqldump file protects you against the mariabackup binary breaking after a major-version upgrade; the binlog protects you against silent corruption between backups.
Common pitfalls and error messages to watch for
Even with the right tool, things go wrong. Here are the failure modes the community hits most often in the mysqldump vs mariabackup workflow.
Version mismatch on mariabackup restore
The mariabackup binary version must match the source server’s major.minor, not the upgrade target. If you upgraded from MariaDB 10.4 to 10.5 and now need to restore an old 10.4 backup, you must keep the 10.4 mariadb-backup binary around. The MariaDB Knowledge Base calls this out explicitly in the full-backup-and-restore page. Several forum posts show operators losing hours because they assumed the new binary would read the old backup.
mariabackup –prepare failures
The “mariabackup failed to apply redo log” error usually means a corrupted backup file or an interrupted prepare step. Always run mariadb-backup --prepare --target-dir=... with enough disk space — the prepare step can briefly double the disk footprint of the backup. If the prepare fails halfway, delete the backup and start over; a partial prepare is not recoverable.
mysqldump silent corruption
The worst-case failure pattern is a mysqldump cron job that looks healthy for months but produces subtly invalid SQL. A Severalnines client postmortem describes silent disk truncation on a NAS that produced 6 weeks of invalid dumps; recovery took 11 days. The fix is a monthly restore drill on a throwaway instance — the single most-mentioned reliability practice on r/mariadb in 2026.
Encryption key management
For mariabackup –encrypt, store the key in a secret manager or a separate offline location. Storing it next to the backup file defeats encryption. For mysqldump encrypted with gpg, use the recipient-key workflow so multiple operators can decrypt, rather than a passphrase that walks out the door with the operator who set it.
Cross-version import issues
mysqldump from MariaDB 11.0+ emits sandbox-mode SQL at the top of the file that older MySQL clients cannot parse. If you must load such a dump into MySQL 8.0, strip the first few sandbox-mode comments or take the dump with --no-sandbox. MariaDB 11.4.1 added parallel dump via --tab --parallel for tab-separated output that loads cleanly into either server.
Frequently Asked Questions
What is the difference between mysqldump and mariabackup?
mysqldump (also called mariadb-dump in MariaDB 11.0+) produces a logical backup — a text file of SQL statements that recreate your schema and data. mariabackup (now officially mariadb-backup) produces a physical backup — a binary copy of InnoDB data files taken while the server runs, then made consistent by replaying the InnoDB redo log in the prepare step.
Is mariabackup faster than mysqldump?
Yes, substantially. On a 100 GB InnoDB database mariabackup completes the backup in 5 to 15 minutes and the restore in 10 to 30 minutes, while mysqldump takes 45 to 90 minutes to back up and several hours to replay. The advantage grows with database size.
Can mysqldump take hot backups?
Yes for InnoDB and Aria when you use the u002du002dsingle-transaction flag, which issues START TRANSACTION WITH CONSISTENT SNAPSHOT and keeps the dump consistent against a live workload without blocking writes. For MyISAM or mixed-engine servers you must use u002du002dlock-tables, which acquires a global read lock for the duration of the dump.
Does mariabackup lock the database during backup?
mariabackup takes essentially no locks on InnoDB tables — it copies data files directly while the server runs and replays the InnoDB redo log to make the snapshot consistent. It briefly locks MyISAM and Aria tables at the very end of the backup to flush them, usually a few seconds.
Which is better for large MariaDB databases: mysqldump or mariabackup?
mariabackup. Once a database is over about 10 GB the restore time becomes the dominant factor, and mariabackup restores are roughly 10x faster than mysqldump because they are file copies plus InnoDB crash recovery rather than SQL replay with index rebuilds. For Galera clusters mariabackup is the recommended SST method at any size.
Can I restore a mysqldump file into MariaDB?
Yes. A mysqldump file is plain SQL and loads cleanly with mariadb client or mysql client across most major versions. A mysqldump from MariaDB 11.0+ may contain sandbox-mode SQL at the top that older MySQL clients cannot parse; strip those comments or use u002du002dno-sandbox if you need to load it into MySQL 8.0.
What are the disadvantages of mysqldump?
The main disadvantages are slow restore time on large databases, memory pressure without u002du002dquick, blocking locks without u002du002dsingle-transaction, no native incremental backups, no built-in compression or encryption, and the silent-corruption failure mode where a bad dump looks healthy in the cron log but fails on restore. mariabackup addresses most of these at the cost of binary-version coupling.
How do I choose between logical and physical MariaDB backups?
Pick logical (mysqldump) for small databases, cross-version migrations, CI seeding, partial restores of single tables, and schema snapshots you want to read or version-control. Pick physical (mariabackup) for any production server over 10 GB, Galera clusters, tight RTO targets, incremental chains, encrypted backups, and any environment where restore time matters more than portability. Most production teams run both in a hybrid strategy.
Conclusion
The mysqldump vs mariabackup decision is not really a competition. Logical and physical backups serve different operational needs, and the right answer for most MariaDB teams in 2026 is to run both: mariabackup nightly as your fast-restore primary, mysqldump weekly as a portable archive, and continuous binary log shipping for point-in-time recovery. Use the decision matrix in this guide to size your primary tool, run monthly restore drills, and keep your encryption keys in a place that is not the same disk as your backup files. That is the playbook that survives a real outage.