How to back up a MariaDB Docker container (2026)
The correct way to back up a MariaDB container is a logical dump, not a file copy. Run `mariadb-dump --all-databases --single-transaction --routines --triggers -uroot -p"$MARIADB_ROOT_PASSWORD"` inside the container and back up its output. Copying /var/lib/mysql while MariaDB is writing produces an inconsistent snapshot; --single-transaction wraps the dump in one InnoDB transaction, capturing every table at a single consistent point without a write lock.
What Dockstash detects
| Env keys detected | MARIADB_ROOT_PASSWORD, MYSQL_ROOT_PASSWORD, MARIADB_DATABASE, MARIADB_USER |
|---|---|
| Default port | 3306 |
| Live data paths (never copied live) | /var/lib/mysql |
| Example images | mariadb:11, mariadb:10.11, mariadb:10, mariadb |
Back up MariaDB with Dockstash, step by step
Create your Dockstash account and open the dashboard
Sign up free at app.dockstash.com/register. The one-time setup wizard asks for your storage VPS (the machine that will hold the encrypted backups) and generates an encryption password — save that password in a password manager immediately, it is shown exactly once.
Add the Docker project that runs MariaDB
On the Projects screen Dockstash auto-detects every Compose project folder on the server (by default under /var/www). Pick the project that contains your MariaDB service. Nothing is backed up yet — you are just telling Dockstash where the project lives.
Check that MariaDB was detected
Open the project and look at the Plan tab. Dockstash reads docker-compose.yml, recognizes the mariadb image, and adds a database layer with the right dump command — plus the container name it resolved and the env keys it found (MARIADB_ROOT_PASSWORD, or the legacy MYSQL_ROOT_PASSWORD, plus MARIADB_DATABASE and MARIADB_USER). You can toggle files, databases, and proxy configs on or off before saving.
Optional: sanity-check the dump by hand
If you want proof before automating, run the same dump Dockstash will run — mariadb-dump with --single-transaction. You should see SQL stream out: CREATE DATABASE, CREATE TABLE, and INSERT statements. That output is what gets backed up, never the live /var/lib/mysql directory.
docker exec <mariadb-container> sh -c 'mariadb-dump --all-databases --single-transaction -uroot -p"$MARIADB_ROOT_PASSWORD"' | head -n 20Confirm your storage destination
Backups are stored as encrypted restic snapshots on your own storage VPS over SSH. If you completed the setup wizard this is already configured; you can change host, user, port, or the SSH key any time under Settings → Storage.
Set a backup schedule
On the project’s Schedule tab pick daily, weekly, or a custom cron expression (validated inline). Daily at a quiet hour is the right default for most MariaDB projects. Add a weekly prune schedule with your retention policy so old snapshots are trimmed automatically.
Run the first backup now
Click Backup Now on the project card. Dockstash executes mariadb-dump with --single-transaction, --routines, and --triggers inside the running container and streams the dump straight into restic — you can watch the live restic output line by line in the log panel while it runs.
Confirm the snapshot exists
When the run finishes, the project card shows the new last-backup time, snapshot count, and repository size. Open the Snapshots screen and you will see the restore point in the timeline — that is your proof the backup landed off-site.
The dump command
mariadb-dump --all-databases --single-transaction --routines --triggers -uroot -p"$MARIADB_ROOT_PASSWORD"The restore command
mariadb -uroot -p"$MARIADB_ROOT_PASSWORD"--single-transaction wraps the dump in one InnoDB transaction, capturing every table at a single consistent point without a write lock.
Restore a MariaDB backup and prove it works
A MariaDB backup is only real once it has restored. Dockstash restores never overwrite your live database by default — you restore to a fresh location first, check the data, and promote it deliberately.
Pick a restore point
Open Snapshots, select the project, and browse the timeline of restore points. Each row is a complete single-point-in-time dump of every database on the server — schemas, data, routines, and triggers — plus the project files captured in the same run.
Restore to a new location
Click Restore and keep the default "Restore to new location" mode. Type the project name to confirm — this is a deliberate, typed-confirm action. The dump and files land in the target path you choose, leaving the live project untouched.
Verify the restored data
Load the restored dump into a scratch MariaDB container, then run SHOW DATABASES through the mariadb client to confirm every schema came back, and spot-check the tables your app depends on. Row counts and recent records are the quickest truth test.
docker exec <mariadb-container> sh -c 'mariadb -uroot -p"$MARIADB_ROOT_PASSWORD" -e "SHOW DATABASES;"'Promote when satisfied
Once the restored data checks out, point your app at it (or repeat the restore with "Overwrite existing" — an explicit opt-in). Better: let the weekly restore drill do this proof automatically so a restore is never your first rehearsal.
Gotchas to avoid
- Never restic the live /var/lib/mysql directory — a mid-write InnoDB copy is unrestorable.
- Newer images ship mariadb-dump; older ones use mysqldump. Dockstash detects which binary the image provides.
- MariaDB accepts either MARIADB_ROOT_PASSWORD or the legacy MYSQL_ROOT_PASSWORD env key, so both are detected.
Common MariaDB backup problems
- Symptom
- Running the dump by hand fails with "mariadb-dump: command not found".
- Cause
- Older MariaDB images (10.4 and earlier) only ship the mysqldump binary; mariadb-dump arrived later, with mysqldump kept as a compatibility symlink on new images.
- Fix
- Use mysqldump with the same flags on older images — the output is identical. Dockstash detects which binary the image provides and calls the right one automatically.
- Symptom
- The dump fails with "Access denied for user 'root'@'localhost'".
- Cause
- The root password env key in compose (MARIADB_ROOT_PASSWORD or the legacy MYSQL_ROOT_PASSWORD) no longer matches the password inside the data volume — the env var only sets the password on first initialization.
- Fix
- Use the password the volume was initialized with, or reset the root password inside the container, then align the compose env so detection and the dump agree.
- Symptom
- Restoring the dump into a MySQL container errors on syntax.
- Cause
- MariaDB and MySQL have drifted — MariaDB features like sequences, certain collations, and storage options do not exist in MySQL, so a cross-engine restore can break.
- Fix
- Restore into a MariaDB image of the same major version the dump came from. Only attempt a MariaDB → MySQL migration deliberately, after cleaning the dump.
- Symptom
- A backup run fails with a stale restic lock after a crash or reboot.
- Cause
- A previous job died mid-run and left the repository locked.
- Fix
- Nothing to do manually: the next run detects the orphaned lock and runs restic unlock automatically before proceeding. If runs keep failing, check the live log panel for the underlying error.
Do it in one click with Dockstash
Dockstash runs the exact dump above, restics it off-site, and drill-tests the restore automatically — no script to maintain.
Last updated: July 2026
Frequently asked questions
Is MariaDB backed up the same way as MySQL?
Almost identically. Both use --single-transaction for a consistent InnoDB snapshot. The difference is the client binary: recent MariaDB images ship mariadb-dump (mysqldump is a compatibility symlink). Dockstash picks the right one.
Which root password env key does Dockstash detect?
Both MARIADB_ROOT_PASSWORD and the older MYSQL_ROOT_PASSWORD are recognized, since MariaDB images accept either depending on version.
Can I restore a MariaDB dump into MySQL or vice versa?
Often, but not always — feature and syntax drift between the two can break edge cases. Restore into the same engine family the dump came from for a reliable result.
Why not just snapshot the volume?
The /var/lib/mysql volume is written continuously. A snapshot mid-write is inconsistent. A logical dump via mariadb-dump is the restorable path.
How often should I back up MariaDB?
Daily is the practical default for most projects; hourly if losing a day of writes is unacceptable. On the Free tier backups are manual only; Pro allows schedules up to hourly, Business any cron. Pair the schedule with a weekly restore drill so every week you get proof the backup actually restores.
Where do the backups actually live?
On your own storage VPS, as encrypted restic snapshots pushed over SSH. Dockstash never holds your data on a third-party cloud — you point it at a box you control, and the repository is encrypted with a password only you have.
How do I know the backup is restorable without doing a manual restore?
Schedule a restore drill. Dockstash restores the latest snapshot into an isolated scratch workspace, byte-hashes every file against the source, and row-diffs the restored dump — then stamps a pass/fail badge on the project. A weekly drill means you always have fresh proof.