MariaDB backup strategy: where it differs from MySQL

MariaDB still speaks a familiar protocol and supports much of the SQL and tooling associated with MySQL. That familiarity is useful until a recovery plan quietly assumes the two products are the same. Server internals, system tables, authentication, storage engines, client behavior, and release numbering have continued to diverge. A backup that can be created through a compatible connection is not automatically a backup that can be restored by either product or by any nearby version.

Put the exact source on the recovery sheet: MariaDB edition, full server version, operating system, architecture, storage engines in use, character sets, plugins, encryption configuration, and whether the server belongs to a replica set or Galera cluster. Record the dump or physical-backup client version separately. This is not inventory for its own sake. It determines which recovery software must be available after the original host is gone.

The logical export client is named mariadb-dump. MariaDB retained mysqldump as an alternate name for compatibility, but its documentation says that name is deprecated from MariaDB 11.0 and is removed from the MariaDB Docker Official Image. A scheduled job that merely expects a mysqldump executable can therefore fail after an otherwise routine image update. Pin and test the client you intend to run rather than relying on a historical alias.

There is also a restore-side compatibility trap. Current mariadb-dump output begins with a command that enables sandbox mode. MariaDB documents that older MariaDB command-line clients and MySQL's mysql client cannot interpret it. This is precisely the kind of detail a backup-only check misses: the export completes, the archive is retained, and the first clean restore fails before useful data is loaded. A rehearsal should use the client family and version planned for recovery, not whichever SQL client happens to be installed on an engineer's laptop.

Logical dumps remain a good fit when portability, a single database, or selective inspection matters more than the shortest possible restore time. Keep output from failed jobs distinct from completed artifacts, watch duration and size, and treat warnings as failures requiring review. Large servers may expose the single-threaded nature of mariadb-dump through long backup and recovery windows, at which point a physical strategy deserves evaluation.

Single-transaction logical backups are attractive because InnoDB can provide a consistent snapshot while applications continue to read and write. MariaDB's own documentation limits that guarantee to transactional tables capable of the required consistent snapshot. Aria, MyISAM, MEMORY, and other non-transactional tables can change while the export is running. DDL such as ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, or TRUNCATE TABLE can also invalidate the result.

MariaDB deployments are more likely than a generic “MySQL-compatible” checklist suggests to contain a deliberate mix of engines. Aria is used in the MariaDB ecosystem, MyRocks may appear in specialized installations, and legacy MyISAM tables are not rare. Query the actual server and classify every non-temporary table. If one important table falls outside the consistency guarantee, either coordinate writes, use an appropriate physical tool, or accept and document the weaker recovery point. Do not label a dump consistent based only on the dominant engine.

MariaDB supplies mariadb-backup for physical online backups. It supports InnoDB, Aria, and MyISAM, with additional documented support for features such as encrypted tables and MyRocks. This is not a reason to substitute a MySQL physical-backup product or an arbitrary Percona XtraBackup build. MariaDB's tool originated from XtraBackup years ago, but compatibility must be judged against the current MariaDB server and the vendor's version guidance.

A completed physical copy is not immediately ready to start. Data files are copied at different moments, so the backup has to be prepared before restoration to make the files consistent. MariaDB warns that InnoDB rejects an unprepared backup as corrupt. Recovery then replaces an empty data directory while the target server is stopped. Those constraints make a physical restore a server-level operation with a larger blast radius than importing one logical database.

Physical backups earn their complexity on large datasets and recovery-time objectives that make SQL replay too slow. They can also form full and incremental chains. Test the whole chain, including preparation, because losing one required base or incremental set can make later pieces useless. Preserve encryption keys and plugin configuration under separate protection; copied encrypted tablespaces are not enough when the recovery environment cannot decrypt them.

Tables are only the visible center of a MariaDB application. Triggers, stored routines, scheduled events, views, users, grants, time-zone data, and plugins can affect behavior after a restore. MariaDB documents triggers as part of normal table dumps, while routines and events need explicit coverage. Server-wide accounts and privileges also have a different recovery impact from one application's schema and rows.

Avoid treating the mysql system database as a portable bundle of identities across MariaDB and MySQL versions. System-table layouts and upgrade work differ, and MariaDB uses mariadb-upgrade to bring system tables into line with the installed release. For a same-version full-server recovery, an appropriately tested physical backup may preserve the expected server state. For migration or selective recovery, document how accounts and grants will be recreated and inspect them in the target instead of assuming that restoring system tables is harmless.

A nightly logical or physical backup returns the server to a nightly boundary. Recovering to a moment between those runs requires retained binary logs that cover the interval from a suitable base backup. MariaDB's point-in-time recovery documentation describes restoring the base and then replaying binary-log changes to the chosen position or time. The base backup and log archive therefore form one recovery system; either half alone cannot deliver the claim.

Set binary-log retention from the recovery window rather than from spare disk space. Verify that log coordinates are associated with the base, that logs leave the database host before local expiry, and that an operator can stop replay before the damaging transaction. Galera or replication does not replace this history. Replicas copy valid writes and accidental writes alike, while a cluster can lose several members to one operational mistake.

Rehearse on a clean MariaDB target that matches the intended recovery version. For a logical backup, inspect object coverage, import errors, definers, character sets, routines, events, grants, and representative application queries. For a physical backup, prove that preparation completes, the server starts without recovery errors, encrypted data is readable, and every required engine or plugin loads. In both cases, measure elapsed time and storage needed for temporary working copies.

Repeat the test after a major MariaDB upgrade, a change of Docker image, a new storage engine, or a switch in backup client. Include one older recovery point rather than only the newest artifact. The most valuable result is often a discovered dependency: the obsolete client that cannot parse the dump, the forgotten key-management file, or the restore time that exceeds the outage budget. Fixing that while production is healthy is the purpose of the exercise.