MariaDB Backups
mysqldump vs binary backup: which one, and how long does a restore really take?
Backup isn't the problem — restore time is what actually defines your RTO. Here's how to choose between mysqldump and binary backup (mariabackup), when to use which, and how long restores really take depending on the size of your database.
Why this question matters
Many teams inherit a nightly cron with a mysqldump running overnight. It works fine — until the day you actually have to restore a 500 GB database in production. That's when you discover the restore takes 18 hours, during which the service is down.
The choice between logical (mysqldump) and binary (mariabackup) backup is not really about the backup itself — it's about your actual RTO: how long your business stays down when things go wrong.
mysqldump: logical backup, SQL format
mysqldump produces a plain-text SQL file containing the CREATE TABLE and INSERT statements that rebuild your database. It's the historical, universal format, restorable on any MariaDB or MySQL version.
Its big strength: portability. A SQL dump taken from MariaDB 10.6 restores without drama on MariaDB 11.x or even on MySQL. Ideal for migrations, version upgrades, or small databases.
Its big weakness: restore replays every INSERT one by one, then rebuilds every index. On a database with many secondary indexes, the "rebuild indexes" step can account for 70% of the restore time.
mariabackup: binary backup, file copy
mariabackup (a fork of Percona XtraBackup adapted to MariaDB) performs a physical hot copy of your database InnoDB files, without blocking application writes. The result is a binary copy ready to be put back in place.
Restore boils down to copying the files back and starting MariaDB. No SQL replay, no index rebuild. On a 1 TB database, you go from about 40 hours (mysqldump) to about 3 hours (mariabackup).
mariabackup also supports page-level incrementals: only the InnoDB pages modified since the last full backup are saved. Perfect for a weekly full + daily incrementals strategy.
The trade-off: binary backups are tied to the major version and storage engine. A backup taken on MariaDB 10.6 doesn't restore on MariaDB 11.x without an intermediate step.
Side-by-side comparison
Neither tool is universally "better" — each addresses a specific need.
| Criterion | mysqldump | binary backup (mariabackup) |
|---|---|---|
| Format | Plain SQL text (INSERT statements) | Physical copy of InnoDB / Aria data files |
| Lock impact | Locks tables (or long transaction with --single-transaction) | Hot backup, no application-visible lock |
| Backup speed (100 GB) | Hours — limited by SQL serialization | Minutes — disk-throughput bound |
| Restore speed (100 GB) | Very slow — replays every INSERT, rebuilds every index | Fast — copies files back, no index rebuild |
| Portability | Restores on any MariaDB/MySQL version | Tied to the same major version and storage engine layout |
| Incremental | Not really — full dump every time | Yes, page-level incrementals supported |
| Point-in-time recovery | Requires combining with binlogs | Requires combining with binlogs |
| Best for | Small bases, migrations, version upgrades | Production, multi-TB bases, fast restore SLA |
Real-world restore times by database size
Indicative figures on standard infrastructure (NVMe SSD, typical indexing). Your real numbers depend on index count, fragmentation, and disk throughput.
| Database size | mysqldump | binary backup (mariabackup) | Verdict |
|---|---|---|---|
| 10 GB | ~15–30 min | ~2–5 min | Small base, both methods are acceptable. |
| 100 GB | ~3–6 h | ~15–30 min | Gap starts to hurt. Binary preferred. |
| 1 TB | ~30–60 h | ~2–4 h | mysqldump becomes a business risk: 1+ day of downtime. |
| 5 TB | Impractical (days) | ~10–20 h | Only binary backup is operationally viable. |
Point-in-Time Recovery (PITR): neither mysqldump nor mariabackup is enough on its own
Whether you use mysqldump or mariabackup, at best you have a daily snapshot — that is, an RPO of 24h. If the database is corrupted at 4 pm, you'll lose everything written since last night's backup.
The real protection comes from MariaDB binary logs (binlogs), which record every committed transaction. By combining a full backup + binlogs up to T-1 minute, you can restore the database to the exact timestamp just before the incident.
In practice, our operational stack combines: weekly full mariabackup, daily incremental mariabackup, continuously streamed binlogs off-site. RPO of a few minutes, measured RTO, and quarterly restore tests.
RPO and RTO: the only numbers that matter
RPO (Recovery Point Objective)
How much data you accept to lose. A nightly mysqldump cron = 24h RPO. Streaming binlogs = RPO of a few minutes.
RTO (Recovery Time Objective)
How long you remain down before being operational again. On 1 TB, mysqldump implies an RTO of 30+ hours. mariabackup brings it down to 3–4 hours.
Many companies advertise a theoretical 4h RTO in their BCP — without ever having tested it. An untested backup is not a backup, it's a hope.
MariaDB backup best practices
- Binary backup (mariabackup) for production, with daily incrementals.
- mysqldump as a complement for small databases, migrations and exports.
- Continuous streaming of binlogs off the production server.
- Backup storage on separate infrastructure (ideally a different datacenter).
- Quarterly restore drill on an isolated environment — not just "the file exists".
- Up-to-date restore procedure: what you want at 3 am is a runbook, not Stack Overflow.
- Encryption of backups at rest, encrypted transit to the off-site location.
How RDEM Systems operates MariaDB backups
Every managed MariaDB cluster benefits from a 3-2-1 strategy adapted to SQL databases: 3 copies of the data, 2 different media, 1 off-site copy.
Binary backups are orchestrated by Signal18 Replication Manager on the replica to avoid impacting primary performance. Binlogs are continuously streamed to our NimbusBackup infrastructure.
A quarterly restore drill is performed on an isolated environment. The result (actual duration, integrity) is documented and shared with you. No "Schrödinger backups" — we know whether it works.
Does your backup strategy actually hold up in production?
A MariaDB audit includes a full review of your backup strategy and a measured restore test.
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