Are you using someone else’s backup solution for your MySQL data? Do you care a lot about your data? Are you sure you’re getting a reliable, recoverable backup that’ll work for your business and your application, and won’t impact your critical processes while it runs? Here are ten questions you need to be able to answer:
- Does the backup require shutting down MySQL? If not, what is the impact on the running server? Blocking, I/O load, cache pollution, etc?
- What technique is used for the MySQL backup? Is it mysqldump or a custom product that does something similar? Is it a filesystem copy?
- Does the backup system understand that you cannot back up InnoDB by simply copying its files?
- Does the backup use FLUSH TABLES, LOCK TABLES, or FLUSH TABLES WITH READ LOCK? These all interrupt processing.
- What other effects are there on MySQL? I’ve seen systems that do a RESET MASTER, which immediately breaks replication. Are there any FLUSH commands at all, like FLUSH LOGS?
- How does the system guarantee that you can perform point-in-time recovery?
- How does the system guarantee consistency with the binary log, InnoDB logs, and replication?
- Can you use the system to set up new MySQL replication slaves? How?
- Does the system verify that the backup is restorable, e.g. does it run InnoDB recovery before declaring success?
- Does anyone stand behind it with support, and guarantee working, recoverable backups? How strong is the legal guarantee of this and how much insurance do they have?
There are a lot of other things a backup solution needs to provide, but these are some of the things I’d require specifically for MySQL, or more so for MySQL than for other types of backups.
Where is this post coming from? Well, I’ve had a couple of frustrating encounters with vendors who sell backup products with some kind of agent for MySQL database backup. I am almost never able to get any significant technical detail on how their backups are implemented, and often I can’t even get the most basic information such as “dump or file copy.” Sometimes they tell me to register and download a whitepaper that just has a bullet point “Support for MySQL Databases”. Or “I have to transfer you to the salesperson who covers your region” and I never get to talk to anyone.
Some of them even use the word “proprietary” as if it’s a good thing. In reality, a proprietary, secret backup black-box is unacceptable. MySQL backups are complex and difficult to get right. It is very application-dependent and technology-dependent. Unless I know exactly how it works, I cannot tell the client whether it’ll work for them at all.
So I offer the above list as a way to evaluate your backup provider’s suitability for enterprise-ready backup uses. If you can’t answer these questions, it’s a system that you can’t evaluate seriously, in my opinion.