Two numbers to know
- How long would it take to be running again?
- How much data would you lose?
Most businesses have never established either number. Both are knowable in an afternoon, and both frequently turn out to be worse than assumed.
What needs backing up
- The database, obviously and most importantly
- Uploaded files, which are commonly outside the database backup
- Configuration and environment variables
- The code, which should be in version control anyway
- Any credentials needed to rebuild the environment
A restore that recovers the database and not the uploaded documents is a partial restore, and it is the most common gap.
Test the restore
- Take the most recent backup
- Restore it to a clean environment
- Check the application runs and the data is complete
- Time it, honestly
- Write down what was missing or awkward
An hour, once, and you will know whether your backups are real. The problems it finds are exactly the ones you do not want to discover during an incident.
Document the recovery
| Needed | Why |
|---|---|
| Where backups are | Findable under pressure |
| How to restore, step by step | Someone other than the author can do it |
| Credentials needed | Available without the usual person |
| DNS and domain access | Pointing at a new server |
| Who to contact | Hosting, provider, developer |
Decide what is acceptable
For some businesses a day of downtime and an hour of lost data is fine. For others it is not, and the arrangements need to reflect that.
The point is deciding deliberately rather than discovering the answer at the worst possible moment.