Ten Things to Remember About MySQL Backups

In today’s data-driven world, ensuring the safety of your valuable data is crucial.

To safeguard this data using MySQL, implementing a robust backup strategy is essential.

For this, we have mentioned ten important things to consider while dealing with MySQL backups. Let’s learn them in detail below.

MySQL Backups

10 Things You Must Do While Backing Up MySQL

Here are ten important considerations to keep in mind when dealing with MySQL backups.

1. Use Hot Backups

Hot backups are an excellent way to back up MySQL. They can run without blocking your application, and save tons of restore time. Percona’s xtrabackup tool is a great way to do this.  We wrote a how-to on using xtrabackup for hotbackups.

2. Use Logical Backups

Just because we love hot backups using xtrabackup doesn’t mean mysqldump isn’t useful.  Want to load data into Amazon RDS?  Want to isolate and load only one schema, or just one table?  All these great uses make mysqldump indispensable.  Use it in combination with periodic hot backups to give you more recovery options.

3. Replication isn’t a backup

While replication provides a great way to keep a hot copy of your production database, it’s not the same as a backup.  Why?  Operator error, that’s why!  People make mistakes, drop tables and database schemas that later need to be restored.  This can and will happen, so head off the disaster by doing real backups.

As an additional note, if you’re using replication, you surely want to perform regular checksums of your data.  These ensure that the primary and secondary do indeed contain the same data.

4. Fire drills & Restore Time

The only way to be sure your backup is complete is to test restoring everything. Yes, it’s a pain, but it will inevitably be a learning experience.  You’ll document the process to speed it up in future tests, you’ll learn how long recovery takes, and find additional pieces to the pie that must be kept in place.

Different backups have different recovery times. In the industry vernacular, your RTO or recovery time objective should inform what will work for you. Although a mysqldump may take 30 minutes to complete, your restore of that data might take 8 hours or more.

That’s due in part to rebuilding all those indexes. When you perform the dump, one create index statement is formulated from the data dictionary, but on import, the data must be sorted and organized to rebuild the index from scratch.

Percona’s mysqldump utility will capitalize on MySQL’s fast index rebuild for Innodb tables. According to the Percona guys this can bring a big improvement in import time. Yet another great reason to use the Percona distro!

5. Transaction Logs

If you want to be able to do point-in-time recovery, you’ll need all the binlog files as well.  These are being created all the time, while new transactions are completed in your database.

If your last backup was last night at 3 am, and you want to recover today until 3 pm, you’ll need all the binary logs from the intervening hours to apply to that backup. This process is called point-in-time recovery and can bring your database restore up to the current committed transactions.

6. Backup Config Files

Don’t forget that lonely /etc/my.cnf file.  That’s an important part of a backup if you’re rebuilding on a newly built server.  It may not need to be backed up with the same frequency but should be included.

7. Stored Code & Grants

Stored procedures, triggers, and functions are all stored in the mysql database schema.  If you are doing a restore of just one database schema, you may not have this, or it may make the restore more complicated.

So, it can be a good idea to backup code separately. mysqldump can do this with the –routines option.  Hot backups by their nature, will capture everything in the entire instance – that is all database schemas including the system ones.

Grants are another thing you may want to backup separately. For the same reasons as stored code, grants are stored in the system tables. Percona toolkit includes a nice tool for this called pt-show-grants. We recommend running this periodically anyway, as it’ll give you some perspective on permissions granted in your database. You’re reviewing those right?

8. Events & Cronjobs

MySQL allows the running of events inside the database. SHOW EVENTS or SHOW EVENTS schema_name will display the events scheduled.

You may also have cronjobs enabled. Use crontab -l to display those for specific users.  Be sure to check at least “mysql” and “root” users as well as other possible application users on the server.

9. Monitoring

Backups are a nitpicky job, and often you don’t know if they’re complete until it’s time to restore. That’s why we recommend firedrills above, and they’re very important. You can also monitor the backups themselves. Use an error log with mysqldump or xtrabackup, and check that logfile for new messages.

In addition, you can check the size of the resulting backup file. If it has changed measurably from the recent backup sizes, it may indicate problems. If your backup size is 0, something serious is wrong. Half the size of recent ones, it may have failed halfway through, or the filesystem filled up.

10. Security

This is an often-overlooked area but may be a concern for some environments. Is the data contained in your backup sensitive? Consider where the backups are stored and retained for the long term. Reason who has access to those files, and make use of the least privileges rule.


All the important things to remember about MySQL backups are discussed above and we hope you have found this guide helpful on learning these. By understanding and implementing these ten key considerations, you can safeguard your data and ensure its availability even in the face of unforeseen challenges. Thanks for reading!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *