MariaDB Backup and Restore Checklist 2026: 7 Steps

Follow our 2026 MariaDB backup and restore checklist with 7 expert steps. Protect your data with proven backup strategies. Start now!

Running a small website means your database holds everything — your blog posts, user accounts, and product data. If something goes wrong, you lose it all. That is why having a solid MariaDB backup and restore checklist is one of the most important things you can do. This guide walks you through every step in simple language. No expert skills needed.

Quick Summary – MariaDB Backup and Restore Checklist at a Glance

Before we dive deep, here is a fast overview. This MariaDB backup and restore checklist covers the key steps you need to protect your small website database. You will learn how to back up your data, store it safely, and bring it back if something breaks.

Prerequisites for MariaDB Backup and Restore

Before you start, make sure you have these things ready:

  • A server running MariaDB (version 10.5 or newer is best)
  • SSH access to your server (or terminal access)
  • Enough disk space for your backup files
  • A text editor to create scripts (like nano or vim)
  • Basic knowledge of command-line operations

MariaDB Backup Checklist (One-Page Overview)

  1. Check your database size and health
  2. Choose your backup method (mariabackup or mysqldump)
  3. Run the backup command
  4. Verify the backup file is complete
  5. Compress the backup to save space
  6. Move a copy to offsite storage
  7. Set up a schedule for regular backups

MariaDB Restore Checklist (One-Page Overview)

  1. Stop the MariaDB service
  2. Clear or prepare the data directory
  3. Run the restore command
  4. Fix file permissions
  5. Start the MariaDB service
  6. Test that your data is intact
  7. Check your website works normally

How to Choose the Right MariaDB Backup Method for Your Small Website

Not all backups are the same. The MariaDB backup and restore checklist starts with picking the right method. There are two main options for small websites.

Physical Backup (mariabackup) vs Logical Backup (mysqldump)

Feature mariabackup (Physical) mysqldump (Logical)
Speed Faster for large databases Slower but simpler
Backup Size Smaller files Larger files
Ease of Use More complex steps Very easy to use
Best For Databases over 1GB Small websites under 1GB
Hot Backup Yes, no downtime Yes, with –single-transaction

When to Use mariabackup for MariaDB Backup

Use mariabackup when your database is growing fast. If your site has many users or large tables, mariabackup saves time. It copies the actual database files. This means faster backups and faster restores. It also supports incremental backups, which only save what changed since the last backup.

When to Use mysqldump for MariaDB Backup

Use mysqldump when your database is small. Most small websites have databases under 1GB. For these, mysqldump is perfect. It creates a plain text SQL file. You can open it, read it, and even edit it. It works on any system. This makes it the best choice for the MariaDB backup and restore checklist of a small website.

MariaDB Backup Checklist: Step-by-Step Instructions

Now let us go through the full MariaDB backup and restore checklist for backing up your database. Follow each step carefully.

Pre-Backup Verification Steps for MariaDB

Before you run any backup command, check these items first:

  1. Check disk space: Run df -h to see if you have enough room. Your backup needs at least as much space as your database.
  2. Check database health: Run mysqlcheck --all-databases -u root -p to find any broken tables.
  3. Note your MariaDB version: Run mariadb --version. Write it down. You need the same version when restoring.
  4. Check running processes: Run mysql -u root -p -e "SHOW PROCESSLIST" to see if anything unusual is happening.

Performing a Full Backup with mariabackup

Follow these steps to create a full physical backup:

  1. Step 1: Install mariabackup if needed. Run sudo apt install mariadb-backup on Ubuntu/Debian.
  2. Step 2: Create a backup folder. Run sudo mkdir -p /backup/mariadb.
  3. Step 3: Run the backup command: sudo mariabackup --backup --target-dir=/backup/mariadb/full -u root -p
  4. Step 4: Prepare the backup for restore. Run sudo mariabackup --prepare --target-dir=/backup/mariadb/full
  5. Step 5: Verify the backup. Check that files exist in the target directory with ls -la /backup/mariadb/full.

Performing a Logical Backup with mysqldump

This is the easiest method for small websites. Here is how to do it:

  1. Step 1: Create a backup folder. Run mkdir -p /backup/mariadb.
  2. Step 2: Back up all databases. Run: mysqldump --all-databases --single-transaction --routines --triggers -u root -p > /backup/mariadb/full_backup_$(date +%Y%m%d).sql
  3. Step 3: Or back up a single database. Run: mysqldump --single-transaction -u root -p mydatabase > /backup/mariadb/mydatabase_$(date +%Y%m%d).sql
  4. Step 4: Compress the file to save space. Run gzip /backup/mariadb/full_backup_*.sql
  5. Step 5: Check the file size. Run ls -lh /backup/mariadb/ to confirm it looks right.

Securing and Storing Your MariaDB Backup Offsite

A backup on the same server is not safe. If the server fails, you lose both. Follow these steps:

  1. Step 1: Use rsync to copy backups to another server. Run: rsync -avz /backup/mariadb/ user@remote-server:/backups/mariadb/
  2. Step 2: Or upload to cloud storage. Use tools like rclone to send files to Google Drive, AWS S3, or Dropbox.
  3. Step 3: Encrypt your backups. Run: gpg -c /backup/mariadb/full_backup.sql.gz to add a password.
  4. Step 4: Keep at least 3 copies in different locations.

MariaDB Backup Retention Strategy for Small Websites

Do not keep every backup forever. You will run out of space. Use this simple rule:

  • Keep daily backups for 7 days
  • Keep weekly backups for 4 weeks
  • Keep monthly backups for 6 months

You can automate cleanup with a cron job. Run find /backup/mariadb/ -name "*.sql.gz" -mtime +7 -delete to remove files older than 7 days.

MariaDB Restore Checklist: Step-by-Step Recovery Guide

Sometimes things go wrong. When they do, your MariaDB backup and restore checklist helps you recover fast. Follow these steps.

Pre-Restore Preparation Steps for MariaDB

  1. Step 1: Identify which backup to restore. Check dates and file sizes.
  2. Step 2: Stop the MariaDB service. Run sudo systemctl stop mariadb.
  3. Step 3: Back up the current data directory just in case. Run sudo cp -r /var/lib/mysql /var/lib/mysql_old.
  4. Step 4: Check that your backup file is not corrupted. For SQL files, run gunzip -t backup.sql.gz.

Restoring a Full Physical Backup with mariabackup

  1. Step 1: Make sure MariaDB is stopped. Run sudo systemctl stop mariadb.
  2. Step 2: Clear the data directory. Run sudo rm -rf /var/lib/mysql/*.
  3. Step 3: Copy the backup files back. Run sudo mariabackup --copy-back --target-dir=/backup/mariadb/full.
  4. Step 4: Fix file ownership. Run sudo chown -R mysql:mysql /var/lib/mysql.
  5. Step 5: Start MariaDB. Run sudo systemctl start mariadb.
  6. Step 6: Verify the restore. Run mysql -u root -p -e "SHOW DATABASES".

Restoring a Logical Backup with mysqldump

  1. Step 1: Make sure MariaDB is running. Run sudo systemctl start mariadb.
  2. Step 2: Decompress the backup if needed. Run gunzip full_backup.sql.gz.
  3. Step 3: Restore all databases. Run: mysql -u root -p < /backup/mariadb/full_backup.sql
  4. Step 4: Or restore a single database. Run: mysql -u root -p mydatabase < /backup/mariadb/mydatabase.sql
  5. Step 5: Check the result. Log in and run SHOW TABLES to confirm your data is back.

Point-in-Time Recovery Using Binary Logs in MariaDB

Sometimes you need to go back to a specific moment. Binary logs make this possible.

  1. Step 1: Make sure binary logging is enabled. Add log-bin to your MariaDB config file.
  2. Step 2: Restore your last full backup first.
  3. Step 3: Find the binary log files. They are usually in /var/lib/mysql/.
  4. Step 4: Apply the binary logs. Run: mysqlbinlog /var/lib/mysql/mysql-bin.000001 | mysql -u root -p
  5. Step 5: To stop at a specific time, add --stop-datetime="2026-01-15 10:00:00" to the command.

Post-Restore Validation Checklist for MariaDB

After restoring, always check these items:

  • Run SHOW DATABASES to see all databases are present
  • Run SELECT COUNT(*) FROM important_table to check row counts
  • Test your website — load pages, submit forms, check login
  • Check the MariaDB error log: sudo tail -50 /var/log/mysql/error.log
  • Verify user permissions still work

Automating Your MariaDB Backup and Restore Checklist

Doing backups by hand is risky. You will forget. Automation makes your MariaDB backup and restore checklist run on its own.

Scheduling Automated MariaDB Backups with Cron

  1. Step 1: Open the cron editor. Run crontab -e.
  2. Step 2: Add a daily backup line. For example: 0 2 * * * /usr/bin/mysqldump --all-databases --single-transaction -u root -pYourPassword > /backup/mariadb/daily_$(date +\%Y\%m\%d).sql
  3. Step 3: This runs every day at 2 AM. Adjust the time to when your site has the least traffic.
  4. Step 4: Save and exit. Cron will now run this command automatically.

Sample Backup Script Template for Small Websites

Create a file called backup.sh with this content:

  • Set the date variable for file naming
  • Run mysqldump with the correct flags
  • Compress the output with gzip
  • Remove backup files older than 7 days
  • Copy the new backup to offsite storage
  • Log the result so you know it worked

Then make it executable with chmod +x backup.sh and add it to your cron schedule.

Automating MariaDB Restore Tests

A backup is useless if it does not work. Test your restores regularly:

  1. Step 1: Set up a test server or a Docker container with MariaDB.
  2. Step 2: Write a script that restores your latest backup to the test server.
  3. Step 3: Run basic queries to check the data is correct.
  4. Step 4: Schedule this test weekly with cron.
  5. Step 5: Get an email alert if the test fails.

Common MariaDB Backup and Restore Mistakes to Avoid

Even with a good MariaDB backup and restore checklist, people make mistakes. Here are the most common ones.

Skipping the --prepare Step in mariabackup

The --prepare step makes your backup consistent. Without it, the backup may have unfinished transactions. Always run mariabackup --prepare before trying to restore. Skipping this step is the number one reason physical backups fail.

Restoring Into a Non-Empty Data Directory

mariabackup will not work if the data directory has files in it. Always clear /var/lib/mysql/ before restoring a physical backup. For mysqldump, this is not a problem since it uses SQL commands.

Forgetting File Permissions After MariaDB Restore

After a physical restore, the files might have wrong ownership. MariaDB needs the mysql user to own all files. Always run sudo chown -R mysql:mysql /var/lib/mysql after restoring. Without this, MariaDB will not start.

Not Testing Your MariaDB Backup Restoration Regularly

Many people make backups but never test restoring them. This is dangerous. You might find out your backup is broken at the worst time. Test your MariaDB backup and restore checklist at least once a month.

Troubleshooting MariaDB Backup and Restore Errors

Errors happen. Here is how to fix the most common ones in your MariaDB backup and restore checklist.

Fixing "Tablespace" Errors After MariaDB Restore

If you see "tablespace not found" errors, it usually means the InnoDB data files are out of sync. To fix this:

  1. Stop MariaDB.
  2. Remove the ibdata1 file and log files from the data directory.
  3. Make sure you ran --prepare on the backup.
  4. Restore again with mariabackup --copy-back.
  5. Fix permissions and restart.

Resolving Permission Denied Errors in MariaDB Restore

Permission errors usually mean the mysql user cannot read the files. Check these:

  • Run ls -la /var/lib/mysql/ to see who owns the files.
  • Run sudo chown -R mysql:mysql /var/lib/mysql to fix ownership.
  • Run sudo chmod -R 750 /var/lib/mysql to set correct permissions.
  • Check if AppArmor or SELinux is blocking access.

Handling Version Mismatch Errors in mariabackup

If your backup was made with MariaDB 10.5 but you restore on 10.11, you may get errors. The fix is simple: use the same MariaDB version for backup and restore. If you must upgrade, restore first on the old version, then upgrade MariaDB after the data is loaded.

FAQ: MariaDB Backup and Restore Checklist Questions

How Often Should I Back Up My MariaDB Database?

For most small websites, daily backups are enough. If your site changes a lot (like an online store), back up every 6 hours. The key is to back up often enough that you can accept the data loss between backups.

Can I Restore a MariaDB Backup to a Different Server?

Yes. For mysqldump backups, you can restore on any server with the same or newer MariaDB version. For mariabackup, the versions should match closely. Also check that both servers use the same operating system architecture (both 64-bit, for example).

What Is the Fastest Way to Restore MariaDB?

Physical backups with mariabackup are the fastest to restore. They copy files directly. Logical restores with mysqldump are slower because MariaDB must re-run every SQL command. For small websites, the difference is small. For large databases, mariabackup can be 10 times faster.

How Do I Verify My MariaDB Backup Is Working?

The only way to know is to test restoring it. Set up a test server. Restore your backup there. Run queries to check the data. If everything looks correct, your MariaDB backup and restore checklist is working well.

Conclusion and Final MariaDB Backup and Restore Recommendations

A good MariaDB backup and restore checklist is not optional. It is the most important safety step for your small website. Here are the key takeaways:

  • Choose mysqldump for simple, small databases. Choose mariabackup for larger or growing databases.
  • Automate your backups with cron. Never rely on manual backups.
  • Store backups in at least 3 places — local, remote, and cloud.
  • Test your restores every month. A backup you cannot restore is not a backup.
  • Keep your MariaDB version consistent between backup and restore servers.

Start today. Run your first backup now. Then set up automation. Your future self will thank you when something goes wrong and you can restore in minutes instead of hours.