Choosing the best MariaDB backup tools comes down to your database size, your tolerance for downtime, and where you want the copies to live. After years of running MariaDB clusters in production and helping teams recover from accidental DROP TABLE incidents, I’ve seen firsthand how the right backup tool — paired with a tested restore procedure — can turn a near-disaster into a routine Tuesday.
In this guide, I’ll walk you through the seven tools I trust most in 2026: the native mariabackup, the ever-present mysqldump, Percona XtraBackup, the parallel mydumper/myloader pair, PHPBU, phpMyBackupPro, and a few honourable mentions. You’ll get a clear decision framework, code examples, cloud-storage setup, and the best practices that separate a backup from a verified backup.
Whether you’re running a small WordPress site on shared hosting or a multi-terabyte MariaDB 11.x cluster, this article gives you the practical playbook I’d hand to a junior DBA on day one.
Table of Contents
Logical vs Physical vs Hot Backup: The Foundations
Before picking a tool, you need to understand the three backup methodologies that every MariaDB backup tool fits into. Logical backups read your data and emit SQL statements; physical backups copy the underlying data files; hot backups do either without taking the database offline.
A logical backup is a text file of CREATE TABLE, INSERT, and GRANT statements generated by mysqldump or mariadb-dump. It’s portable across MariaDB versions and easy to grep, but it gets slow once your database exceeds a few gigabytes. A physical backup copies InnoDB data files, redo logs, and table definitions byte-for-byte. It restores faster and is what you want on a 100 GB+ production database.
A hot backup is a backup taken while MariaDB is running and serving queries. The native mariabackup tool accomplishes this with a backup lock that pauses writes for a fraction of a second, captures changed pages, and ships a consistent snapshot. A cold backup requires you to shut MariaDB down first — safe but rarely practical in production.
| Backup Type | How It Works | Database Stays Online? | Best For |
|---|---|---|---|
| Logical | Dumps SQL statements | Yes (with --single-transaction) | Small DBs, migrations, version upgrades |
| Physical | Copies raw data files | Yes (with backup lock) | Large production DBs, fast restore |
| Hot | Physical or logical while running | Yes | 24/7 production systems |
| Cold | DB shut down, files copied | No | Maintenance windows, snapshots |
Most production teams combine two of these. A daily physical backup via mariabackup gives you a fast full restore; continuous binary-log archiving gives you point-in-time recovery down to the second. That’s the foundation of every robust MariaDB backup strategy.
How to Choose the Right MariaDB Backup Tool for Your Setup
Picking the right tool isn’t about feature lists — it’s about matching the tool to your actual constraints. I always ask three questions before recommending anything: how big is the database? how fast do I need to recover? and who’s running the backups?
If you’re running a database under 5 GB on shared PHP hosting, mysqldump or phpMyBackupPro is plenty. Between 5 GB and 100 GB, mariabackup with daily incrementals is the sweet spot. Above 100 GB, parallel tools like mydumper cut backup windows dramatically — teams report 5-10x speedups on large InnoDB workloads. If you don’t have shell access, a PHP-based tool like PHPBU or phpMyBackupPro runs as a cron-driven PHP script instead.
| Your Situation | Recommended Tool | Why |
|---|---|---|
| Small DB, shared hosting | mysqldump / phpMyBackupPro | Zero install, runs from web UI |
| Medium DB, full SSH | mariabackup | Hot backup, native MariaDB support |
| Large DB, performance-critical | mydumper + mariabackup | Parallel threads, fastest restore |
| PHP-only environment | PHPBU / phpMyBackupPro | Pure PHP, cron-friendly |
| Legacy MariaDB 10.1-10.4 | Percona XtraBackup 2.4 | Last XtraBackup branch with MariaDB support |
| Need point-in-time recovery | mariabackup + binary logs | Full + incremental chain to the second |
My recommendation for most teams reading this in 2026: start with mariabackup for full daily snapshots and binary-log shipping for point-in-time recovery. Add mysqldump if you need a quick SQL-text export for development or migration work. That two-tool combination covers roughly 80% of real-world cases.
mysqldump: The Built-In Logical Backup Tool
mysqldump ships with every MariaDB and MySQL server. It produces a single SQL file containing CREATE TABLE, INSERT, and grant statements that you can pipe into a fresh MariaDB instance to recreate your schema and data exactly. Because it is bundled with the server itself, no separate install is required.
The classic invocation looks like this:
mysqldump --single-transaction --quick --routines --triggers
--events --hex-blob --default-character-set=utf8mb4
-u backup_user -p my_database > my_database_$(date +%F).sqlThe --single-transaction flag wraps the dump in a single transaction, giving you a consistent snapshot of InnoDB tables without locking writes. --quick streams rows instead of buffering them in memory, which matters on large tables.
Pros: universal availability, portable SQL output, easy to inspect and edit, restores anywhere, works on every storage engine. Cons: slow on databases over ~10 GB, doesn’t capture server-level config or users without --system=all, no native incremental support, requires mysqldump-compatible client to restore.
For tiny databases or one-off exports, mysqldump is genuinely unbeatable. For anything else, pair it with mariabackup rather than trying to scale it.
mariabackup: The Native Hot Backup for MariaDB 10.5+
mariabackup is the MariaDB Server project’s official physical backup tool, and on MariaDB 10.5 and later it is the recommended way to take hot backups. It was forked from Percona XtraBackup but has since diverged with MariaDB-specific features.
A basic full backup looks like this:
mariabackup --backup
--target-dir=/var/backups/mariadb/full/$(date +%F)
--user=backup_user --password=secret
mariabackup --prepare
--target-dir=/var/backups/mariadb/full/$(date +%F)The --backup step copies data files while MariaDB keeps running. The --prepare step applies the redo log so the snapshot is crash-consistent and ready to restore.
Incremental backups work by capturing only the data pages that changed since the last full backup:
mariabackup --backup
--target-dir=/var/backups/mariadb/inc/$(date +%F)
--incremental-basedir=/var/backups/mariadb/full/2026-09-01
--user=backup_user --password=secretWhere mariabackup really shines is on MariaDB 11.x. It understands system-versioned tables (so you can restore historical row versions), encrypted tablespaces (including InnoDB page-level encryption), and the backup locks introduced in MariaDB 10.5 (which replace the older FLUSH TABLES WITH READ LOCK).
Pros: native MariaDB integration, hot online backups, incremental + differential support, AES-256 encryption, parallel file copy, supports system-versioned and encrypted tablespaces. Cons: binary-only output (less portable), requires enough disk space for the working directory, restoration is to a stopped server, no built-in scheduling.
If you run MariaDB 10.5 or later in production and care about point-in-time recovery, mariabackup should be your default.
Percona XtraBackup: The Mature Physical Backup Alternative
Percona XtraBackup is the original open-source hot physical backup tool for InnoDB, and for years it was the de facto choice for both MySQL and MariaDB. MariaDB forked it into mariabackup, so on MariaDB 10.5+ you should prefer mariabackup. XtraBackup still has its place on MySQL and on older MariaDB versions where mariabackup doesn’t ship.
Usage looks nearly identical to mariabackup:
xtrabackup --backup --target-dir=/var/backups/xb/full
--user=backup_user --password=secret
xtrabackup --prepare --target-dir=/var/backups/xb/fullThe key differences: XtraBackup 8.0+ targets MySQL 8 only, XtraBackup 2.4 was the last branch to support MariaDB 10.x and MySQL 5.7. It does not understand MariaDB-specific features like system-versioned tables or LOCK TABLES FOR BACKUP.
Pros: mature, well-documented, large community, parallel file copy, encryption support. Cons: no MariaDB-specific features, latest 8.x releases are MySQL-only, requires Percona Server or MySQL 5.7/8.0 for some features.
Use XtraBackup if you’re on MySQL or on a MariaDB version before 10.5. On MariaDB 11.x, mariabackup is the better choice.
mydumper and myloader: Parallel Backups for Large Databases
mydumper is a logical backup tool — but unlike mysqldump it runs multiple parallel threads, so each thread dumps a chunk of tables simultaneously. The companion myloader restores those chunks in parallel too. This is what gives you the 5-10x speedup that production teams report on 100 GB+ InnoDB databases.
Example usage:
mydumper --threads=8
--outputdir=/var/backups/mydumper/$(date +%F)
--compress --build-empty-files
--rows=1000000
--user=backup_user --password=secret
myloader --threads=8
--directory=/var/backups/mydumper/2026-09-12
--user=backup_user --password=secret --overwrite-tablesThe --rows=1000000 flag splits each table into chunks of one million rows, which lets myloader parallelise the restore. --compress applies zstd compression on the fly.
Pros: parallel threads (multi-core friendly), consistent snapshot across all threads, faster than mysqldump on large DBs, consistent with MySQL GTIDs and MariaDB replication. Cons: not bundled with the server, requires separate install, no incremental support, SQL output still less compact than physical backups.
For very large databases where restore time matters more than file size, mydumper/myloader is the right tool. Pair it with mariabackup if you also need incrementals.
PHPBU: PHP-Native Backups with Cloud Storage Support
PHPBU is a PHP-based backup framework that’s especially relevant for the phpmybackuppro.net audience. It runs as a PHP script under cron, supports MariaDB (and MySQL) via mysqldump or native PDO, and ships with built-in collectors for S3, Google Cloud Storage, Azure Blob, Backblaze B2, Dropbox, SFTP, and WebDAV.
A minimal phpbu.xml configuration:
<phpbu xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<backups>
<backup>
<collector name="mysqldump">
<option name="host" value="localhost"/>
<option name="user" value="backup_user"/>
</collector>
<target name="s3" type="bucket">
<option name="bucket" value="my-mariadb-backups"/>
<option name="region" value="us-east-1"/>
</target>
<cleanup type="max-age">
<option name="max-age" value="30"/>
</cleanup>
</backup>
</backups>
</phpbu>Pros: pure PHP, runs on shared hosting with cron, encrypts with AES-256 before upload, supports retention policies, built-in cloud destinations, no shell access required. Cons: depends on mysqldump under the hood (so it’s logical only), not ideal for very large databases, requires PHP 7.4+.
PHPBU is the right pick when you want full automation in a PHP-only environment and your database is in the small-to-medium range.
phpMyBackupPro: Web-Based Backups for PHP Environments
phpMyBackupPro is a long-running PHP web application that gives you a browser dashboard for scheduling and managing MariaDB backups. It runs entirely from a single PHP file and a MySQL/MariaDB connection, which is why it’s still popular on shared hosting and legacy LAMP stacks.
Set it up by uploading the script, opening it in your browser, configuring your database credentials, and picking a schedule. The tool writes SQL dumps and (optionally) zips them, optionally uploads them to an FTP server, and keeps a history of every run. It also has a manual “Backup Now” button — useful for one-off captures before a risky migration.
Pros: zero shell access needed, web UI for non-CLI users, scheduled SQL dumps, FTP upload, multi-database support, free and open source. Cons: logical dumps only, no compression beyond gzip, no cloud storage beyond FTP, no encryption built-in, UI is dated compared to modern tools.
If you’re running a small PHP site and just need a safety-net backup once a day, phpMyBackupPro is still one of the simplest ways to get there.
MariaDB Backup Tools at a Glance: Comparison Table
Here’s a side-by-side comparison of the seven best MariaDB backup tools covered in this guide.
| Tool | Type | Hot Backup | Incremental | Encryption | Built-in Scheduling | Cost |
|---|---|---|---|---|---|---|
| mysqldump | Logical | Yes (–single-transaction) | No | No | No | Free |
| mariabackup | Physical | Yes | Yes | AES-256 | No | Free |
| Percona XtraBackup | Physical | Yes | Yes | AES-256 | No | Free |
| mydumper / myloader | Logical (parallel) | Yes | No | No | No | Free |
| PHPBU | Logical (PHP) | Yes | No | AES-256 | Yes (cron) | Free |
| phpMyBackupPro | Logical (web) | Yes | No | No | Yes (built-in) | Free |
| Bacula Enterprise | Physical + Logical | Yes | Yes | AES-256 | Yes | Paid |
Every tool above is free and open source except Bacula Enterprise, which I’ve included as the enterprise-grade option for teams that need centralised policy management across many databases.
How to Back Up MariaDB to S3, Google Cloud, and Backblaze
Storing backups only on the same server as your database is a single point of failure. Push them to a remote object store — ideally in a different region — and you’ve satisfied the “offsite” half of the 3-2-1 rule.
For Amazon S3 with mariabackup, the cleanest pipeline is: take the backup locally, prepare it, then sync to S3 with the AWS CLI:
mariabackup --backup --target-dir=/var/backups/full
--user=backup_user --password=secret
mariabackup --prepare --target-dir=/var/backups/full
aws s3 sync /var/backups/full s3://my-mariadb-backups/full/$(date +%F)/
--storage-class STANDARD_IAThe --storage-class STANDARD_IA flag puts older backups in Infrequent Access storage, which is cheaper and perfectly suited to “we only need this if disaster strikes” data.
For Google Cloud Storage, swap the AWS CLI for gsutil:
gsutil -m rsync -r /var/backups/full
gs://my-mariadb-backups/full/$(date +%F)/For Backblaze B2, the rclone tool handles it cleanly:
rclone sync /var/backups/full b2:my-mariadb-backups/full/$(date +%F)/
--transfers=8 --checkers=16For a PHP-only workflow, PHPBU’s built-in S3/GCS/Azure/B2 collectors mean you don’t need to write any of the above — declare the destination in your phpbu.xml and let it upload encrypted backups on schedule.
One more tip: enable S3 Object Lock or B2 Object Lock for your backup bucket. It prevents ransomware that compromises your application server from also deleting the offsite copies.
MariaDB Backup Best Practices: 3-2-1, Encryption, and Restore Testing
A backup you haven’t restored from is a hope, not a backup. The teams I trust most all follow the same handful of practices — let me walk you through the ones that matter most in 2026.
The 3-2-1 rule is the foundation: keep 3 copies of your data, on 2 different media, with 1 copy offsite. For MariaDB this typically means: the live database, a local disk or NAS backup, and a cloud bucket in another region. The rule exists because every storage medium fails eventually — disks die, NAS units get ransomware’d, cloud accounts get compromised.
Encrypt every backup at rest. Both mariabackup and PHPBU support AES-256 encryption natively. Add TLS in transit by using https:// endpoints for S3, GCS, and B2. Treat your backup encryption keys with the same care as database credentials — if you lose them, the backups are useless.
Test your restores on a schedule. Pick a cadence — monthly is a good starting point — and actually restore the most recent backup to a fresh MariaDB instance. Run a smoke-test query, check row counts against the source, then tear it down. I’ve seen teams discover their backups were silently corrupt for six months because nobody had ever restored them.
Set retention policies. Don’t keep every backup forever. A sensible default is: 7 daily, 4 weekly, 12 monthly. PHPBU and most cloud storage providers let you automate this with lifecycle rules or the --max-age cleanup collector.
Automate with cron. The simplest reliable scheduler on Linux is cron. Here’s a daily job that runs mariabackup, prepares the snapshot, and ships it to S3:
0 2 * * * /usr/local/bin/mariadb-backup-and-ship.sh
Where mariadb-backup-and-ship.sh chains the backup, prepare, and aws s3 sync commands shown earlier. Capture stderr to a log file and pipe it to your monitoring system.
For point-in-time recovery, also enable binary logging on your MariaDB instance and ship the binary logs to S3 (or another store) every few minutes. Combined with a daily physical backup, this gives you recovery down to the second.
MariaDB-Specific Advantages: Why mariabackup Beats XtraBackup on MariaDB 11.x
If you’ve been using Percona XtraBackup out of habit, the past few MariaDB releases are a good reason to switch. mariabackup has accumulated MariaDB-specific features that XtraBackup simply doesn’t understand, and on MariaDB 10.5+ it’s the only tool that handles them correctly.
System-versioned tables (temporal tables in MariaDB 10.3+) store historical row versions. mariabackup captures the historical data alongside the current state. XtraBackup treats them as ordinary InnoDB tables and may skip the versioning metadata, which means your “historical” restore loses history.
Encrypted tablespaces (MariaDB 10.1+) let you encrypt InnoDB data files at rest. mariabackup preserves the encryption keys and re-encrypts data on prepare. With XtraBackup on MariaDB, you can hit subtle key-management bugs during prepare.
Backup locks (MariaDB 10.5+) replaced the older FLUSH TABLES WITH READ LOCK pattern. mariabackup issues LOCK TABLES FOR BACKUP, which only blocks writes that touch file structure — DML continues unimpeded. This makes hot backups effectively zero-downtime on busy databases.
For MariaDB 11.x, I recommend mariabackup exclusively. If you also run MySQL 8.x instances, keep XtraBackup around for those — but don’t use it on MariaDB 11.x in production.
Frequently Asked Questions
What is the best backup tool for MariaDB?
The best MariaDB backup tool depends on your database size. For most production deployments, mariabackup is the top pick because it supports hot backups, incrementals, and MariaDB-specific features like system-versioned tables. mysqldump is the right choice for small databases, while mydumper handles very large InnoDB workloads in parallel.
Is MariaDB backup free?
Yes. MariaDB ships mariabackup and mysqldump at no cost, and both are open source under the GPL. Percona XtraBackup, mydumper, PHPBU, and phpMyBackupPro are also free and open source. You only pay if you choose a commercial option like Bacula Enterprise or a managed SaaS platform.
What is the difference between mysqldump and mariadb-backup?
mysqldump produces a logical SQL-text backup and is best for small databases and migrations. mariabackup produces a physical backup of the data files and supports hot backups, incremental backups, and MariaDB-specific features. mariabackup is faster on large databases but the output is binary rather than SQL text.
How do I backup a MariaDB database automatically?
Use a cron job that runs mariabackup for the snapshot, prepares it, then syncs it to a cloud bucket. PHPBU is the PHP-native alternative if you don’t have shell access. Most teams schedule daily full backups, ship binary logs every few minutes for point-in-time recovery, and verify restores monthly.
Does MariaDB have a built-in backup tool?
Yes. MariaDB ships mysqldump (also called mariadb-dump) and mariabackup as part of the server distribution. You don’t need to install any extra packages to use either tool on a standard MariaDB install.
How do I schedule MariaDB backups?
Schedule MariaDB backups with cron on Linux. A typical setup is a daily mariabackup job at 02:00, plus binary-log shipping every five minutes. For PHP environments without cron access, phpMyBackupPro’s built-in scheduler or PHPBU invoked from a web cron service works.
What is mariabackup used for?
mariabackup is MariaDB Server’s official physical backup tool. It takes hot online backups of InnoDB data files, supports incremental and differential backups, applies AES-256 encryption, and understands MariaDB-specific features like system-versioned tables and encrypted tablespaces.
What is the 3-2-1 backup rule?
The 3-2-1 backup rule means keep 3 copies of your data, on 2 different storage media, with 1 copy offsite. For MariaDB this typically means the live database, a local disk or NAS backup, and a cloud bucket in a different region. It protects against disk failure, ransomware, and site-level disasters.
How often should I back up MariaDB?
Back up MariaDB at least daily for full snapshots, plus continuous binary-log archiving if you need point-in-time recovery. The exact frequency depends on your recovery point objective (RPO): a site that can tolerate an hour of data loss might run hourly incrementals, while a payments database typically needs five-minute binary-log shipping.
Can MariaDB do hot backups?
Yes. MariaDB supports hot backups through mariabackup, which uses backup locks (LOCK TABLES FOR BACKUP) introduced in MariaDB 10.5 to capture a consistent snapshot without blocking DML. Percona XtraBackup also performs hot backups on MySQL and on older MariaDB versions.
Choosing Your MariaDB Backup Stack in 2026
After walking through every option, my honest recommendation for the best MariaDB backup tools in 2026 is a two-layer setup: mariabackup for daily full snapshots and incrementals, plus binary-log shipping for point-in-time recovery. Add mysqldump for development exports and PHPBU or phpMyBackupPro if your environment is PHP-only. That combination handles roughly 80% of real-world production cases.
Pick a tool today, schedule the first backup tonight, and restore it to a test server this weekend. The backup you haven’t tested isn’t a backup — it’s a hope. With the right MariaDB backup tool, tested on your data, on your infrastructure, you turn that hope into a guarantee.