Regular database backups are one of the most important operational habits for any MySQL deployment, and RHEL 8 provides all the tools you need to implement a solid backup strategy. mysqldump produces portable SQL dumps that are easy to restore and inspect, while mysqlpump adds parallelism for faster exports on larger datasets. This tutorial covers creating consistent single-database and full-server backups with mysqldump, restoring from those dumps, automating nightly backups with cron, using mysqlpump as a parallel alternative, and performing point-in-time recovery using binary logs.

Prerequisites

  • RHEL 8 server with MySQL 8.0 installed and running
  • The MySQL root password (or a backup account with sufficient privileges)
  • Sufficient disk space in the backup destination directory
  • Binary logging enabled in /etc/my.cnf (log_bin) if point-in-time recovery is required

Step 1 — Back Up a Single Database with mysqldump

The --single-transaction flag starts a consistent snapshot for InnoDB tables without locking them, making it safe to run against a live production server. Include stored routines and triggers so the dump is a complete representation of the database.

mysqldump --single-transaction 
          --routines 
          --triggers 
          --events 
          -u root -p 
          mydb > /backups/mydb_$(date +%F).sql

Verify the dump was created and is non-empty:

ls -lh /backups/mydb_$(date +%F).sql

Compress it to save space:

gzip /backups/mydb_$(date +%F).sql

Step 2 — Restore a Database from a Dump File

To restore, create the target database if it does not exist, then pipe the SQL file into MySQL. If the dump is gzip-compressed, decompress on the fly with zcat.

mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS mydb;"
# From a plain .sql file:
mysql -u root -p mydb < /backups/mydb_2026-05-17.sql

# From a compressed .sql.gz file:
zcat /backups/mydb_2026-05-17.sql.gz | mysql -u root -p mydb

Step 3 — Back Up All Databases

Use --all-databases to produce a single dump containing every database on the server, including mysql, information_schema, and user accounts. Add --master-data=2 to record the binary log position as a comment in the dump, which is useful for point-in-time recovery.

mysqldump --all-databases 
          --single-transaction 
          --routines 
          --triggers 
          --events 
          --master-data=2 
          -u root -p > /backups/all_databases_$(date +%F).sql

Step 4 — Automate Backups with Cron

Create a shell script that performs a compressed backup of all databases and deletes dumps older than 14 days. Store the MySQL credentials in a secured option file rather than on the command line.

sudo nano /etc/mysql-backup.cnf
[client]
user     = root
password = YourRootPassword
sudo chmod 600 /etc/mysql-backup.cnf

Create the backup script:

sudo nano /usr/local/bin/mysql-backup.sh
#!/bin/bash
DEST=/backups
DATE=$(date +%F)
mkdir -p "$DEST"
mysqldump --defaults-file=/etc/mysql-backup.cnf 
          --all-databases 
          --single-transaction 
          --routines --triggers --events 
          --master-data=2 | gzip > "$DEST/all_${DATE}.sql.gz"
find "$DEST" -name "all_*.sql.gz" -mtime +14 -delete
sudo chmod +x /usr/local/bin/mysql-backup.sh

Schedule it to run nightly at 2 AM:

sudo crontab -e
0 2 * * * /usr/local/bin/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1

Step 5 — Use mysqlpump for Parallel Backups

mysqlpump backs up multiple databases in parallel threads, significantly reducing dump time on servers with many databases or large tables.

mysqlpump --default-parallelism=4 
          --all-databases 
          --single-transaction 
          --routines 
          -u root -p > /backups/pump_$(date +%F).sql

The --default-parallelism=4 flag instructs mysqlpump to use four parallel dump threads. Adjust the value to match your server’s CPU count.

Step 6 — Point-in-Time Recovery with Binary Logs

If you need to recover data up to a specific moment after the last full backup, use the binary logs. First, restore the most recent full dump, then replay binary log events up to the desired time.

# Step 1: Restore the last full backup
zcat /backups/all_2026-05-17.sql.gz | mysql -u root -p

# Step 2: Find the binary log file and starting position from the dump header
head -50 <(zcat /backups/all_2026-05-17.sql.gz) | grep 'MASTER_LOG'

# Step 3: Replay binary log events up to a target datetime
mysqlbinlog --start-datetime="2026-05-17 02:00:00" 
            --stop-datetime="2026-05-17 14:30:00" 
            /var/lib/mysql/binlog.000042 | mysql -u root -p

Conclusion

You now have a complete MySQL backup and restore strategy on RHEL 8: consistent single-database and full-server dumps with mysqldump, automated nightly cron backups with secure credential storage, parallel exports with mysqlpump, and point-in-time recovery using binary logs. Test your restores regularly in a staging environment — a backup that has never been verified is not a backup you can rely on in an emergency.

Next steps: How to Configure MySQL Primary-Replica Replication on RHEL 8, How to Configure MySQL Group Replication on RHEL 8, and How to Monitor MySQL Performance with the Performance Schema on RHEL 8.