Following up on Ronald Bradford‘s Checked your MySQL recovery process recently? post, I wish to add a prequel.
To see whether you have a clear definition of your backup requirements, ask yourself these questions:
- Is there a backup/restore plan?
- Is there a written backup/restore plan?
- How fast do you need to recover a backup? What’s the longest downtime you will allow from the point of failure to the point of restored, functional database?
- How much data are you willing to lose in case of crash? A second’s worth of data? An hour’s worth? A day’s worth? None?
- Are you willing to allow that the database becomes read-only when taking the backup? Or completely down?
- Are you willing to take the risk that the backup will not be 100% compatible with the data? (Backing up your slave holds this risk)
- Is your manager willing to all that you are willing?
- Is the backup plan known to the management team, or do they just know that “the database has backups“?
The above checklist is by no means complete.
I have a vivid memory of a very good sys admin who failed on the last two points. He had some very sour days when recovering a lost file from tape took much longer than was affordable to some contract.
I found that technical people rarely share the same views as marketing/management. Make sure to consult with the management team; they will have a clearer view on what the company can afford and what it cannot afford.