Automating Daily MariaDB Backups to QNAP on Proxmox

Now that MariaDB runs on my Proxmox host, backing it up properly became a priority. I already back up Apache to my QNAP NAS (see my earlier post on setting up that mount), so it made sense to reuse the same share for the database backups rather than create a second one.

Here’s how I built a daily MariaDB backup with 30-day retention, dumping straight to hass-backups/mariadb on the QNAP.

The plan

Before writing a single line of script, I laid out what the job needed to do:

• Dump every application database in one file (not separate dumps per database) — this makes disaster recovery much simpler
• Skip MariaDB’s internal databases (information_schema, performance_schema, mysql, sys)
• Compress the dump
• Verify the dump actually succeeded before doing anything else
• Delete backups older than 30 days — but only after a successful new backup
• Log everything so I can tell at a glance whether last night’s run worked
• Eventually expose backup status to Home Assistant so my System Health dashboard can flag it if backups stop running

Reusing the existing QNAP mount

Since Apache backups already land on the QNAP, I didn’t need to mount a new share — I just needed to confirm where the existing one lives. On the Proxmox host:

findmnt | grep -i qnap

If that comes back empty, this is a good fallback:

df -h | grep -E 'qnap|hass|backup'

In my case this confirmed the share was already mounted at /mnt/qnap-www-backup, so I just needed to make sure a mariadb folder existed underneath it before touching anything database-related.

Setting up the backup script

I keep my own Proxmox maintenance scripts in /opt/scripts, so that’s where this one lives too:

mkdir -p /opt/scripts
nano /opt/scripts/mariadb-backup.sh

The script dumps all application databases into a single compressed file, verifies the dump, logs the result, and cleans up backups older than 30 days.

The script can be downloaded at the bottom of the blog post.
Once it’s saved, make the script executable:

chmod 750 /opt/scripts/mariadb-backup.sh

Testing it manually

Before trusting this to cron, I ran it by hand:

/opt/scripts/mariadb-backup.sh

The log confirmed a clean run:

Database dump completed.
Backup successful: mariadb_2026-09-17_09-46-35.sql.gz (16K)
MariaDB backup completed successfully.

Scheduling with cron

This is simple host-level maintenance, so cron is a perfectly reasonable choice — no need for a systemd timer here. I scheduled it for 02:30, since my camera system already reboots at 02:00 and I wanted to avoid any overlap:

crontab -e

Add the line:

30 2 * * * /opt/scripts/mariadb-backup.sh >> /var/log/mariadb-backup-cron.log 2>&1

This gives me two logs: the script’s own /var/log/mariadb-backup.log with the detailed run output, and /var/log/mariadb-backup-cron.log for anything cron itself has to say (exit codes, environment issues, etc.).

Verify the job is in place:

crontab -l

My existing Apache backup runs at 02:00 on Sundays only, so the daily 02:30 MariaDB job doesn’t collide with it.

A note on retention

The retention logic uses:

-mtime +30

This means a file isn’t deleted until it’s strictly older than 30 complete 24-hour periods — so in practice you can briefly end up with around 31 daily backups on disk before the oldest one rolls off. That’s intentional: I’d rather keep one extra day than risk deleting a backup slightly early due to how mtime rounds.

Cleaning up and verifying

Once the real scheduled run was confirmed working, I removed my original manual test file:

rm -f /mnt/qnap-www-backup/mariadb/mariadb_test.sql.gz
ls -lh /mnt/qnap-www-backup/mariadb/

And after the first overnight run, I checked both the log and the backup folder:

tail -30 /var/log/mariadb-backup.log
ls -lh /mnt/qnap-www-backup/mariadb/

What’s next

The backup itself is done and running nightly, but I still want to close the loop by exposing the last successful backup timestamp to Home Assistant via MQTT, so it shows up on my System Health dashboard and I get warned automatically if a night’s backup ever fails silently. That’ll likely be a short follow-up post once it’s wired up.

Update Sept 18th 2026:

New script attached with bugfixes.