MariaDB Backup on Mac, AWS, Azure, gCloud

Backups are not insurance until you have restored them

The Backup Rule Nobody Gets to Ignore

A database backup is not a file.
It is not a cron job.
It is not a green checkmark in a cloud console.

A real backup is a proven path back to service.

That means three things:

1. You can restore it.
2. You can restore it fast enough.
3. You can restore it to the point in time the business needs.

MariaDB is reliable, but reliability is not the same as recoverability. Disks fail. Developers drop tables. Ransomware encrypts volumes. Cloud accounts get misconfigured. Replication faithfully copies bad writes. Snapshots expire. Someone eventually runs the wrong command in the wrong terminal.

This guide gives you a practical MariaDB backup playbook across Mac, Linux, AWS, Azure, and Google Cloud. It covers logical backups, physical backups, cloud-native backups, restore examples, scheduling, encryption, retention, and the checks that keep backups from becoming false comfort.

Takeaway

MariaDB backup strategy should combine logical exports, physical backups, cloud snapshots, off-host storage, and regular restore testing.

For small databases, mariadb-dump is simple and portable.

For larger production databases, mariadb-backup is usually the stronger option because it performs physical hot backups.

For AWS RDS, use automated backups, manual snapshots, point-in-time restore, and optional AWS Backup policies.

For Azure, do not design new workloads around Azure Database for MariaDB because that managed service has been retired. Use self-hosted MariaDB on Azure VMs or migrate to Azure Database for MySQL Flexible Server where compatibility allows.

For Google Cloud, distinguish between Cloud SQL for MySQL managed backups and self-hosted MariaDB on Compute Engine.

Most importantly: restore tests are not optional. They are the only proof that the backup works.

1. MariaDB Backup Basics

MariaDB backups usually fall into two categories.

Logical Backups

A logical backup exports SQL statements that can rebuild databases, tables, routines, triggers, users, and data.

Common tool:

mariadb-dump

Older systems may still use:

mysqldump

Logical backups are best when you need portability, selective restore, migration between environments, or simple inspection.

Example:

mariadb-dump -u root -p --single-transaction --routines --triggers --events myapp > myapp.sql

Restore:

mariadb -u root -p myapp < myapp.sql

Physical Backups

A physical backup copies the actual database files in a consistent state.

Common tool:

mariadb-backup

Physical backups are better for larger databases, faster restores, hot backups, and production systems where downtime is expensive.

Example:

mariadb-backup --backup \
  --target-dir=/backups/mariadb/full-$(date +%F) \
  --user=backup \
  --password='StrongPasswordHere'

Prepare the backup:

mariadb-backup --prepare \
  --target-dir=/backups/mariadb/full-2026-06-03

Restore:

systemctl stop mariadb

rm -rf /var/lib/mysql/*
mariadb-backup --copy-back \
  --target-dir=/backups/mariadb/full-2026-06-03
chown -R mysql:mysql /var/lib/mysql
systemctl start mariadb

2. Which Backup Method Should You Use?

Use mariadb-dump When

You have a small to medium database.

You need an easy migration file.

You want to restore one database or table.

You need a human-readable SQL backup.

You want compatibility across environments.

Use mariadb-backup When

You have a large production database.

You need faster backup and restore.

You need hot backups.

You want full and incremental backups.

You are backing up InnoDB-heavy workloads.

Use Cloud Snapshots When

You run MariaDB on managed cloud services or cloud VMs.

You want infrastructure-level recovery.

You need fast rollback of an entire instance.

You want regional or cross-account disaster recovery.

Use More Than One Method When

The database matters.

For production, the best pattern is usually:

Cloud snapshot + physical backup + logical export + restore testing

Each protects against different failure modes.

3. Create a Dedicated MariaDB Backup User

Do not run backups as root unless you have no better option.

Create a backup user:

CREATE USER 'backup'@'localhost' IDENTIFIED BY 'StrongPasswordHere';

GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR, REPLICATION CLIENT
ON *.* TO 'backup'@'localhost';

GRANT SELECT, SHOW VIEW, TRIGGER, EVENT
ON *.* TO 'backup'@'localhost';

FLUSH PRIVILEGES;

For mariadb-backup, extra privileges may be needed depending on your MariaDB version and configuration.

Test the user:

mariadb -u backup -p -e "SHOW DATABASES;"

4. MariaDB Backup on Mac

Mac is common for development, testing, demos, and local apps. The goal is usually simple: export local data safely and make it easy to restore.

Install MariaDB on Mac

Using Homebrew:

brew install mariadb

Start MariaDB:

brew services start mariadb

Check status:

brew services list

Connect:

mariadb -u root

Backup One Database on Mac

mkdir -p ~/mariadb-backups

mariadb-dump -u root -p \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  myapp > ~/mariadb-backups/myapp-$(date +%F).sql

Compress it:

gzip ~/mariadb-backups/myapp-$(date +%F).sql

Result:

myapp-2026-06-03.sql.gz

Restore on Mac

Create the database:

mariadb -u root -p -e "CREATE DATABASE myapp_restore;"

Restore:

gunzip < ~/mariadb-backups/myapp-2026-06-03.sql.gz | \
mariadb -u root -p myapp_restore

Backup All Databases on Mac

mariadb-dump -u root -p \
  --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  --events > ~/mariadb-backups/all-databases-$(date +%F).sql

Compress:

gzip ~/mariadb-backups/all-databases-$(date +%F).sql

Schedule a Mac Backup with LaunchAgent

Create a script:

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

Script:

#!/bin/bash
set -euo pipefail

BACKUP_DIR="$HOME/mariadb-backups"
DATE="$(date +%F-%H%M)"
DB_NAME="myapp"
mkdir -p "$BACKUP_DIR"
mariadb-dump -u root \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  "$DB_NAME" | gzip > "$BACKUP_DIR/$DB_NAME-$DATE.sql.gz"
find "$BACKUP_DIR" -type f -name "*.sql.gz" -mtime +14 -delete

Make it executable:

chmod +x ~/scripts/mariadb-backup.sh

Create LaunchAgent file:

mkdir -p ~/Library/LaunchAgents
nano ~/Library/LaunchAgents/com.local.mariadb-backup.plist

Example:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>com.local.mariadb-backup</string>
    <key>ProgramArguments</key>
    <array>
      <string>/Users/YOUR_USERNAME/scripts/mariadb-backup.sh</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
      <key>Hour</key>
      <integer>2</integer>
      <key>Minute</key>
      <integer>0</integer>
    </dict>
    <key>StandardOutPath</key>
    <string>/tmp/mariadb-backup.out</string>
    <key>StandardErrorPath</key>
    <string>/tmp/mariadb-backup.err</string>
  </dict>
</plist>

Load it:

launchctl load ~/Library/LaunchAgents/com.local.mariadb-backup.plist

Run manually:

~/scripts/mariadb-backup.sh

Mac Takeaway

For Mac, keep it simple. Use mariadb-dump, compress the result, keep a short local retention window, and copy important backups to cloud storage.

5. MariaDB Backup on Linux

Linux is where most self-hosted MariaDB production workloads live. Here, you want discipline: dedicated users, scheduled jobs, off-host storage, encryption, logs, alerts, and restore tests.

Install Backup Tools on Ubuntu or Debian

sudo apt update
sudo apt install mariadb-client mariadb-backup gzip zstd cron

Install Backup Tools on RHEL, Rocky, AlmaLinux, or CentOS

sudo dnf install MariaDB-client MariaDB-backup gzip zstd cronie

Package names can vary by repository and MariaDB version.

Logical Backup on Linux

Create directories:

sudo mkdir -p /backups/mariadb/logical
sudo chown -R root:root /backups
sudo chmod 700 /backups/mariadb/logical

Backup script:

sudo nano /usr/local/sbin/mariadb-logical-backup.sh

Script:

#!/bin/bash
set -euo pipefail

BACKUP_DIR="/backups/mariadb/logical"
DATE="$(date +%F-%H%M)"
MYSQL_CNF="/root/.my.cnf"
BACKUP_FILE="$BACKUP_DIR/all-databases-$DATE.sql.gz"
mkdir -p "$BACKUP_DIR"
mariadb-dump \
  --defaults-extra-file="$MYSQL_CNF" \
  --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --hex-blob | gzip > "$BACKUP_FILE"

sha256sum "$BACKUP_FILE" > "$BACKUP_FILE.sha256"

find "$BACKUP_DIR" -type f -name "*.sql.gz" -mtime +14 -delete
find "$BACKUP_DIR" -type f -name "*.sha256" -mtime +14 -delete

Make it executable:

sudo chmod 700 /usr/local/sbin/mariadb-logical-backup.sh

Create credential file:

sudo nano /root/.my.cnf

Example:

[client]
user=backup
password=StrongPasswordHere
host=localhost

Lock it down:

sudo chmod 600 /root/.my.cnf

Test:

sudo /usr/local/sbin/mariadb-logical-backup.sh

Schedule with cron:

sudo crontab -e

Run daily at 1:30 AM:

30 1 * * * /usr/local/sbin/mariadb-logical-backup.sh >> /var/log/mariadb-logical-backup.log 2>&1

Physical Backup on Linux with mariadb-backup

Create directory:

sudo mkdir -p /backups/mariadb/physical
sudo chown -R mysql:mysql /backups/mariadb/physical

Run full backup:

sudo mariadb-backup --backup \
  --target-dir=/backups/mariadb/physical/full-$(date +%F) \
  --user=backup \
  --password='StrongPasswordHere'

Prepare it:

sudo mariadb-backup --prepare \
  --target-dir=/backups/mariadb/physical/full-2026-06-03

Compress:

sudo tar -I zstd -cf /backups/mariadb/physical/full-2026-06-03.tar.zst \
  -C /backups/mariadb/physical full-2026-06-03

Checksum:

sha256sum /backups/mariadb/physical/full-2026-06-03.tar.zst \
  > /backups/mariadb/physical/full-2026-06-03.tar.zst.sha256

Restore Physical Backup on Linux

Stop MariaDB:

sudo systemctl stop mariadb

Move old data directory:

sudo mv /var/lib/mysql /var/lib/mysql.broken.$(date +%F-%H%M)
sudo mkdir /var/lib/mysql

Restore:

sudo mariadb-backup --copy-back \
  --target-dir=/backups/mariadb/physical/full-2026-06-03

Fix ownership:

sudo chown -R mysql:mysql /var/lib/mysql

Start MariaDB:

sudo systemctl start mariadb

Check:

sudo systemctl status mariadb
mariadb -u root -p -e "SHOW DATABASES;"

Incremental Backup on Linux

Full backup:

sudo mariadb-backup --backup \
  --target-dir=/backups/mariadb/inc/base \
  --user=backup \
  --password='StrongPasswordHere'

First incremental:

sudo mariadb-backup --backup \
  --target-dir=/backups/mariadb/inc/inc1 \
  --incremental-basedir=/backups/mariadb/inc/base \
  --user=backup \
  --password='StrongPasswordHere'

Second incremental:

sudo mariadb-backup --backup \
  --target-dir=/backups/mariadb/inc/inc2 \
  --incremental-basedir=/backups/mariadb/inc/inc1 \
  --user=backup \
  --password='StrongPasswordHere'

Prepare base:

sudo mariadb-backup --prepare \
  --target-dir=/backups/mariadb/inc/base \
  --apply-log-only

Apply first incremental:

sudo mariadb-backup --prepare \
  --target-dir=/backups/mariadb/inc/base \
  --incremental-dir=/backups/mariadb/inc/inc1 \
  --apply-log-only

Apply final incremental:

sudo mariadb-backup --prepare \
  --target-dir=/backups/mariadb/inc/base \
  --incremental-dir=/backups/mariadb/inc/inc2

Restore from the prepared base:

sudo systemctl stop mariadb
sudo rm -rf /var/lib/mysql/*
sudo mariadb-backup --copy-back --target-dir=/backups/mariadb/inc/base
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl start mariadb

Linux Takeaway

On Linux, use mariadb-backup for serious production recovery and mariadb-dump for portability. Store backups off the server. Encrypt them. Test restores. Log every run.

6. Backup to AWS S3 from Linux or Mac

S3 is a common off-host backup target. The pattern is simple:

MariaDB backup → compress → checksum → encrypt → upload to S3 → apply lifecycle policy

Install AWS CLI

On Mac:

brew install awscli

On Linux:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" \
  -o "awscliv2.zip"

unzip awscliv2.zip
sudo ./aws/install

Configure:

aws configure

Upload a Backup to S3

aws s3 cp /backups/mariadb/logical/all-databases-2026-06-03.sql.gz \
  s3://my-mariadb-backups/prod/logical/

Sync Backup Directory

aws s3 sync /backups/mariadb/logical/ \
  s3://my-mariadb-backups/prod/logical/ \
  --storage-class STANDARD_IA

Encrypt Before Upload

Using GPG:

gpg --symmetric --cipher-algo AES256 \
  /backups/mariadb/logical/all-databases-2026-06-03.sql.gz

Upload encrypted file:

aws s3 cp /backups/mariadb/logical/all-databases-2026-06-03.sql.gz.gpg \
  s3://my-mariadb-backups/prod/logical/

S3 Lifecycle Policy

Use lifecycle rules to move older backups to cheaper storage and expire backups after your retention period.

Example retention model:

Daily backups: keep 14 days
Weekly backups: keep 8 weeks
Monthly backups: keep 12 months
Annual backups: keep 7 years if compliance requires it

AWS S3 Takeaway

S3 is not a backup strategy by itself. It is a storage target. Combine it with versioning, encryption, lifecycle rules, least-privilege IAM, and restore tests.

7. MariaDB Backup on AWS RDS

Amazon RDS for MariaDB changes the backup model. You do not manage the underlying data directory. You use AWS-native backups and snapshots.

Recommended AWS RDS Backup Layers

Use automated backups for point-in-time recovery.

Use manual snapshots before risky changes.

Use AWS Backup for central policy management.

Use logical exports when you need portability outside RDS.

Use cross-region copies for disaster recovery.

Enable Automated Backups

Example AWS CLI command:

aws rds modify-db-instance \
  --db-instance-identifier prod-mariadb \
  --backup-retention-period 7 \
  --preferred-backup-window "02:00-03:00" \
  --apply-immediately

This enables a seven-day retention window.

Create a Manual Snapshot

aws rds create-db-snapshot \
  --db-instance-identifier prod-mariadb \
  --db-snapshot-identifier prod-mariadb-before-release-$(date +%F)

Restore an RDS Snapshot

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier prod-mariadb-restore-test \
  --db-snapshot-identifier prod-mariadb-before-release-2026-06-03

Point-in-Time Restore

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-mariadb \
  --target-db-instance-identifier prod-mariadb-pitr-test \
  --restore-time 2026-06-03T01:45:00Z

Logical Export from RDS

Even with RDS backups, a logical export is useful before migrations or major application releases.

mariadb-dump \
  -h prod-mariadb.abc123.eu-west-1.rds.amazonaws.com \
  -u admin \
  -p \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  myapp | gzip > myapp-rds-$(date +%F).sql.gz

Restore Logical Export to Another MariaDB Server

gunzip < myapp-rds-2026-06-03.sql.gz | \
mariadb -h restore-host.example.com -u admin -p myapp

RDS Backup Warning

Do not assume every storage engine behaves equally with managed backups. In production, prefer InnoDB. Avoid odd table engines unless you have tested backup and restore behavior.

AWS RDS Takeaway

For RDS, let AWS handle automated backups and snapshots, but do not stop there. Keep logical exports for portability and run restore tests into non-production instances.

8. MariaDB Backup on Azure

Azure needs a careful distinction.

Get Wayne’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Azure Database for MariaDB, the old managed MariaDB service, has been retired. For new work, you generally have two practical paths:

1. Run MariaDB yourself on Azure Virtual Machines.
2. Migrate compatible workloads to Azure Database for MySQL Flexible Server.

If you need true MariaDB engine behavior, run MariaDB on Azure VMs. If MySQL compatibility is acceptable, Azure Database for MySQL Flexible Server may be the managed target.

Option A: MariaDB on Azure VM

When MariaDB runs on an Azure Linux VM, treat it like a Linux server plus Azure-native storage protection.

Recommended layers:

mariadb-backup
mariadb-dump
Azure managed disk snapshots
Azure Backup
Blob Storage off-host copies

Logical Backup to Azure Blob Storage

Install Azure CLI:

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

Login:

az login

Create a storage account:

az storage account create \
  --name mystorageacct123 \
  --resource-group my-rg \
  --location westeurope \
  --sku Standard_LRS

Create a container:

az storage container create \
  --name mariadb-backups \
  --account-name mystorageacct123

Create backup:

mariadb-dump \
  --defaults-extra-file=/root/.my.cnf \
  --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  --events | gzip > /backups/mariadb/all-databases-$(date +%F).sql.gz

Upload:

az storage blob upload \
  --account-name mystorageacct123 \
  --container-name mariadb-backups \
  --file /backups/mariadb/all-databases-$(date +%F).sql.gz \
  --name prod/all-databases-$(date +%F).sql.gz

Azure VM Disk Snapshot

Find disk:

az vm show \
  --resource-group my-rg \
  --name mariadb-vm \
  --query "storageProfile.osDisk.managedDisk.id" \
  -o tsv

Create snapshot:

az snapshot create \
  --resource-group my-rg \
  --name mariadb-vm-osdisk-$(date +%F) \
  --source /subscriptions/SUB_ID/resourceGroups/my-rg/providers/Microsoft.Compute/disks/DISK_NAME

For better production consistency, stop writes or use database-level backups before taking disk snapshots. A crash-consistent disk snapshot is not the same as an application-consistent MariaDB backup.

Option B: Azure Database for MySQL Flexible Server

If you migrate from MariaDB to Azure Database for MySQL Flexible Server, use MySQL-compatible tooling.

Dump from MariaDB:

mariadb-dump \
  -h old-mariadb-host.example.com \
  -u admin \
  -p \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  myapp > myapp.sql

Restore to Azure MySQL Flexible Server:

mysql \
  -h mymysql.mysql.database.azure.com \
  -u admin \
  -p \
  myapp < myapp.sql

Check compatibility before assuming this will work. MariaDB and MySQL are related, but not identical. Stored procedures, SQL modes, data types, authentication, and optimizer behavior can differ.

Azure Takeaway

Do not build a new plan around the retired Azure Database for MariaDB service. For MariaDB, use Azure VMs and manage backups like Linux. For managed PaaS, evaluate Azure Database for MySQL Flexible Server and test compatibility before migration.

9. MariaDB Backup on Google Cloud

Google Cloud also needs a distinction.

Cloud SQL supports MySQL, PostgreSQL, and SQL Server. It is not a managed MariaDB service in the same way RDS supports MariaDB. For MariaDB specifically, you normally run it yourself on Compute Engine, Google Kubernetes Engine, or another self-managed platform.

If your workload is compatible with MySQL, Cloud SQL for MySQL gives you managed backups. If you need MariaDB-specific behavior, use self-hosted MariaDB and design your own backup pipeline.

Option A: MariaDB on Google Compute Engine

Recommended layers:

mariadb-backup
mariadb-dump
Persistent Disk snapshots
Cloud Storage off-host copies
Backup and DR tooling where appropriate

Install Google Cloud CLI

On Debian or Ubuntu, follow Google’s package method or use the install script.

After install:

gcloud init

Authenticate:

gcloud auth login

Logical Backup to Cloud Storage

Create a bucket:

gcloud storage buckets create gs://my-mariadb-backups \
  --location=europe-west1

Create backup:

mariadb-dump \
  --defaults-extra-file=/root/.my.cnf \
  --all-databases \
  --single-transaction \
  --routines \
  --triggers \
  --events | gzip > /backups/mariadb/all-databases-$(date +%F).sql.gz

Upload:

gcloud storage cp \
  /backups/mariadb/all-databases-$(date +%F).sql.gz \
  gs://my-mariadb-backups/prod/

Google Persistent Disk Snapshot

List disks:

gcloud compute disks list

Create snapshot:

gcloud compute disks snapshot mariadb-data-disk \
  --zone=europe-west1-b \
  --snapshot-names=mariadb-data-disk-$(date +%F)

Again, disk snapshots should not be your only backup. Use mariadb-backup or logical dumps for database-aware recovery.

Option B: Cloud SQL for MySQL

If your workload runs on Cloud SQL for MySQL, use Cloud SQL’s automated and on-demand backups.

Create an on-demand backup:

gcloud sql backups create \
  --instance=my-cloudsql-instance

List backups:

gcloud sql backups list \
  --instance=my-cloudsql-instance

Restore backup:

gcloud sql backups restore BACKUP_ID \
  --restore-instance=my-cloudsql-instance

Logical export from Cloud SQL:

gcloud sql export sql my-cloudsql-instance \
  gs://my-mysql-backups/myapp-$(date +%F).sql \
  --database=myapp

Import:

gcloud sql import sql my-cloudsql-instance \
  gs://my-mysql-backups/myapp-2026-06-03.sql \
  --database=myapp

Google Cloud Takeaway

For MariaDB on Google Cloud, use Compute Engine plus MariaDB-native backups. For MySQL-compatible workloads on Cloud SQL, use Cloud SQL backups and exports.

10. Backup Encryption

Backups often contain the most sensitive copy of your data. They may include customer records, credentials, tokens, emails, financial data, and business history.

Encrypt them.

Encrypt with GPG

gpg --symmetric --cipher-algo AES256 backup.sql.gz

Decrypt:

gpg --decrypt backup.sql.gz.gpg > backup.sql.gz

Encrypt with OpenSSL

openssl enc -aes-256-cbc -salt \
  -in backup.sql.gz \
  -out backup.sql.gz.enc

Decrypt:

openssl enc -d -aes-256-cbc \
  -in backup.sql.gz.enc \
  -out backup.sql.gz

Better Practice

Use managed key systems where possible:

AWS KMS
Azure Key Vault
Google Cloud KMS
HashiCorp Vault

Do not store the encryption key beside the backup.

11. Backup Retention Strategy

Retention should match recovery needs, compliance, storage cost, and operational reality.

A simple production policy:

Hourly transaction logs: 24–48 hours
Daily backups: 14–30 days
Weekly backups: 8–12 weeks
Monthly backups: 12 months
Annual backups: 3–7 years if required

For small systems, this may be enough:

Daily backups: 14 days
Weekly backups: 8 weeks
Monthly backups: 12 months

For regulated systems, retention may be dictated by law or contract.

The Real Question

Do not ask, “How many backups should we keep?”

Ask:

How far back might we need to recover?
How fast must we recover?
How much data can we afford to lose?
Who can approve deletion?
Who can access backup data?

12. RPO and RTO

Two terms matter.

RPO: Recovery Point Objective

How much data can you lose?

Examples:

RPO 24 hours: daily backups are enough.
RPO 1 hour: hourly backups or binlogs are needed.
RPO 5 minutes: replication, binary logs, and PITR are needed.

RTO: Recovery Time Objective

How long can the system be down?

Examples:

RTO 8 hours: manual restore may be acceptable.
RTO 1 hour: documented restore automation is needed.
RTO 5 minutes: standby systems or failover architecture is needed.

Backups alone do not guarantee low RTO. A 500 GB dump file may exist, but restoring it could take hours.

13. Binary Logs and Point-in-Time Recovery

For self-hosted MariaDB, binary logs are essential for point-in-time recovery.

Check binary logs:

SHOW VARIABLES LIKE 'log_bin';
SHOW BINARY LOGS;

Example config:

[mariadb]
log_bin = mariadb-bin
server_id = 1
binlog_format = ROW
expire_logs_days = 7

Restart:

sudo systemctl restart mariadb

A point-in-time restore usually looks like this:

1. Restore the last full backup.
2. Apply binary logs up to the target time.
3. Stop before the destructive query.

Example:

mariadb-binlog \
  --stop-datetime="2026-06-03 14:22:00" \
  /var/lib/mysql/mariadb-bin.000123 | mariadb -u root -p

This is how you recover from mistakes like:

DROP TABLE customers;

or:

UPDATE users SET plan = 'free';

without losing the entire day.

14. Restore Testing

A backup that has never been restored is a hope file.

Create a restore test checklist:

Can we download the backup?
Can we decrypt it?
Does the checksum match?
Can MariaDB start after restore?
Can the app connect?
Do row counts match?
Do critical queries work?
How long did restore take?
Who verified the result?

Monthly Restore Test Example

Create a throwaway VM or container.

Restore the backup.

Run checks:

mariadb -u root -p -e "SHOW DATABASES;"

Count important tables:

SELECT COUNT(*) FROM customers;
SELECT COUNT(*) FROM orders;
SELECT COUNT(*) FROM invoices;

Check application login.

Record restore duration.

Store results in a runbook.

15. Docker-Based Restore Test

A quick logical restore test can use Docker.

Start MariaDB:

docker run --name mariadb-restore-test \
  -e MARIADB_ROOT_PASSWORD=TestPassword123 \
  -e MARIADB_DATABASE=myapp \
  -p 3307:3306 \
  -d mariadb:latest

Restore:

gunzip < myapp-2026-06-03.sql.gz | \
mariadb -h 127.0.0.1 -P 3307 -u root -p myapp

Check:

mariadb -h 127.0.0.1 -P 3307 -u root -p \
  -e "SHOW TABLES FROM myapp;"

Clean up:

docker rm -f mariadb-restore-test

This does not replace a production-grade restore test, but it catches many broken backups fast.

16. Common Backup Mistakes

Mistake 1: Backing Up Only on the Same Server

If the server dies, your backup dies with it.

Fix:

Copy backups off-host.
Use object storage.
Use cross-region copies for critical systems.

Mistake 2: Never Testing Restores

A cron job can run perfectly and still create useless backups.

Fix:

Run scheduled restore drills.
Record results.
Alert on failures.

Mistake 3: No Encryption

Backups often bypass normal application access controls.

Fix:

Encrypt backup files.
Restrict storage access.
Rotate credentials.
Audit access.

Mistake 4: No Retention Policy

Infinite backup retention creates cost and legal risk.

Fix:

Define retention.
Automate deletion.
Protect critical long-term backups from accidental removal.

Mistake 5: Relying Only on Replication

Replication copies mistakes quickly.

Fix:

Use replication for availability.
Use backups for recovery.
Use binary logs for point-in-time restore.

Mistake 6: No Documentation

During an outage, nobody wants to reverse-engineer the backup script.

Fix:

Create a restore runbook.
Keep it short.
Test it.
Update it after every drill.

17. Production Backup Runbook Template

Use this as a starting point.

System

Application:
Database host:
MariaDB version:
Backup type:
Backup location:
Encryption method:
Retention policy:
Owner:
Escalation contact:

Backup Schedule

Logical backup:
Physical backup:
Cloud snapshot:
Binary log retention:
Cross-region copy:

Restore Steps

1. Identify target restore time.
2. Select backup set.
3. Verify checksum.
4. Decrypt backup.
5. Provision restore host.
6. Restore data.
7. Apply binary logs if needed.
8. Start MariaDB.
9. Run integrity checks.
10. Point application or users to restored database.

Validation Queries

SHOW DATABASES;
SHOW TABLES FROM myapp;
SELECT COUNT(*) FROM customers;
SELECT COUNT(*) FROM orders;
SELECT MAX(created_at) FROM orders;

Sign-Off

Restore started:
Restore completed:
Data verified by:
Application verified by:
RTO achieved:
RPO achieved:
Notes:

18. End-to-End Production Script

This script creates a logical backup, compresses it, checksums it, uploads it to S3, and deletes old local files.

#!/bin/bash
set -euo pipefail

APP="myapp"
BACKUP_DIR="/backups/mariadb/logical"
DATE="$(date +%F-%H%M)"
FILE="$APP-$DATE.sql.gz"
PATH_FULL="$BACKUP_DIR/$FILE"
S3_BUCKET="s3://my-mariadb-backups/prod/logical"
mkdir -p "$BACKUP_DIR"
echo "Starting MariaDB backup: $DATE"
mariadb-dump \
  --defaults-extra-file=/root/.my.cnf \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --hex-blob \
  "$APP" | gzip > "$PATH_FULL"
sha256sum "$PATH_FULL" > "$PATH_FULL.sha256"
aws s3 cp "$PATH_FULL" "$S3_BUCKET/$FILE"
aws s3 cp "$PATH_FULL.sha256" "$S3_BUCKET/$FILE.sha256"
find "$BACKUP_DIR" -type f -name "*.sql.gz" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "*.sha256" -mtime +7 -delete
echo "Backup complete: $FILE"

Cron:

15 1 * * * /usr/local/sbin/backup-myapp.sh >> /var/log/backup-myapp.log 2>&1

19. Stronger Backup Architecture

For a serious production MariaDB workload, use this layered model:

Layer 1: Automated cloud snapshot
Layer 2: MariaDB physical backup
Layer 3: Logical export
Layer 4: Binary logs
Layer 5: Offsite object storage
Layer 6: Cross-region replication or copy
Layer 7: Restore testing
Layer 8: Alerting and audit logs

Why so many layers?

Because failure is rarely polite.

A logical dump helps when you need one table.

A physical backup helps when you need fast full restore.

A cloud snapshot helps when the whole VM or managed instance fails.

Binary logs help when someone breaks data at 2:17 PM.

Cross-region storage helps when a region has issues.

Restore testing proves the whole thing works.

20. Backup Checklist

Before calling your MariaDB backup plan “done,” answer these:

Do we have a backup user with limited privileges?
Are backups encrypted?
Are backups copied off-host?
Are backups protected from accidental deletion?
Do we have a retention policy?
Do we monitor backup success and failure?
Do we test restores?
Do we know our RPO?
Do we know our RTO?
Do we know who owns recovery during an incident?
Do we have a written restore runbook?

If the answer to any of these is no, the backup plan is unfinished.

Finally

MariaDB backup is not one command. It is an operating model.

On Mac, use simple dumps and quick restores.

On Linux, use mariadb-backup, mariadb-dump, binary logs, cron or systemd timers, and off-host storage.

On AWS, use RDS automated backups, snapshots, PITR, AWS Backup, and logical exports.

On Azure, treat MariaDB as a self-hosted VM workload or migrate carefully to Azure Database for MySQL Flexible Server.

On Google Cloud, use Compute Engine for self-hosted MariaDB or Cloud SQL backups for MySQL-compatible workloads.

The winning rule is simple:

Do not trust a backup until you have restored it.

#MariaDB #MariaDBBackup #DatabaseBackup #DatabaseRecovery #DevOps #LinuxAdmin #AWSRDS #AzureDatabase #GoogleCloud #CloudSQL #DatabaseSecurity #DisasterRecovery #BackupStrategy #SRE #SysAdmin #DataProtection #MySQL #MariaDBDump #MariaDBBackupTool #CloudBackup

A final word from me…

I hope you found this information insightful and helpful.

If you appreciate my articles, consider buying me a coffee, a simple yet impactful gesture that enables me to continue creating and sharing knowledge in the tech community.

Thank you for considering to supporting me: https://buymeacoffee.com/waynetech ☕️

Core MariaDB documentation references:

• MariaDB Backup and Restore Overview — explains the main MariaDB backup approaches.
• mariadb-backup full backup and restore — source for physical backup, prepare, and restore flow.
• mariadb-backup options — source for --prepare, incremental behavior, and restore preparation notes.
• mariadb-dump documentation — source for logical dump usage and mariadb-dump as the current MariaDB dump utility.

AWS documentation references:

• Amazon RDS automated backups overview — source for automated backups, manual snapshots, and RDS backup behavior.
• Amazon RDS point-in-time restore — source for PITR workflow and restore-to-time behavior.
• Managing RDS automated backups — source for backup window behavior.

Azure documentation references:

• Azure Database for MariaDB retirement announcement — confirms retirement on September 19, 2025 and recommends migration to Azure Database for MySQL Flexible Server.
• Azure Database for MariaDB retirement updates — additional Microsoft migration/retirement guidance.

Google Cloud documentation references:

• Cloud SQL backups overview for MySQL — source for automated/on-demand backups, incremental backups, restore behavior, and encryption.
• Cloud SQL for MySQL documentation — source for Cloud SQL as Google’s managed MySQL platform.
• Google Cloud SQL product page — source for managed database capabilities such as backups, replication, patching, encryption, and storage management.

The official MariaDB docs should be treated as the primary source.