Originally published in 2013. Reworked on 23 October 2026; this revision replaces the previous instructions.
Start with the recovery objective
An SQL file does not prove that an application can be recovered. Define the data you need and its context: database version, schema, configuration and dependencies.
The 2013 article included a password in the command arguments. This revision replaces that example. Credentials should not end up in shell history or copied documentation.
Keep credentials separate
MariaDB can read a private option file accessible only to the backup account. Keep it outside the public directory. This template contains placeholders, not real credentials:
mariadb-dump --defaults-extra-file=/private/path/client.cnf \
--single-transaction --quick database_name > backup.sql--defaults-extra-file must be the first argument. Protect the SQL file too: it may contain personal and application data.
Understand consistency
--single-transaction is useful for transactional tables such as InnoDB. It does not automatically guarantee consistency for other engines, or replace a review of operations taking place during the dump.
Mixed engines and schema changes during backup require an environment-specific procedure.
Test separately
A recovery test must not overwrite production. Use a separate environment, verify the import and check essential application functions with appropriately protected test data.
Record the outcome
Document what was saved, when and how. A successful recovery test is more meaningful than an export command that finished without errors.