Most companies have backups. Far fewer know whether those backups work. The usual discovery happens on the worst day: a disk fails, a person deletes the wrong folder, or a system update goes badly, and the restore either takes much longer than expected or does not work at all.
This article is for heads of technology and operations in smaller companies who run business applications such as an order system, an internal tool or a customer portal. It describes three decisions: what to back up, how often, and how to prove once a quarter that you can get it back. It is about backups and recovery, not about general upkeep; for that, see a maintenance report for leadership.
Step 1: List what the application needs to run again
A database dump is rarely the whole story. Ask a simple question for each application: if the server vanished tonight, what would we need to bring this back?
Typical items:
- Data: the database and any files users upload, such as documents or images.
- Configuration: settings, environment variables, scheduled jobs and connection details to other systems.
- Code and versions: the exact version that was running, or a way to rebuild it.
- Access: the accounts and keys needed to reach the system and the backups themselves, stored where more than one person can reach them.
- Instructions: a short written list of the steps to restore, in the order they must happen.
Write this as one page per application. The act of writing it usually reveals something nobody had saved, such as a file folder that lives only on one server.
Step 2: Decide how often, based on the cost of loss
Frequency should follow one question: how much work can we afford to lose? If an order system loses a day, someone has to re-enter a day of orders. If a rarely changed reference tool loses a week, nobody notices.
A simple way to set it:
- For each application, estimate what the loss of one hour, one day and one week of data would mean in work, money or trust. Rough, honest estimates are enough.
- Choose the longest gap you could accept. That gap is your backup interval.
- Mark the applications where the gap is short, and give them more frequent backups. Leave the rest on a daily or weekly schedule.
Do not apply one schedule to everything. Frequent backups of unimportant systems cost effort and storage, while rare backups of important ones cost far more when something breaks.
Keep several generations, not only the latest copy. A problem such as accidental deletion or corrupted data is sometimes noticed days later, and by then the newest backup already contains it.
Step 3: Keep one copy elsewhere
A backup stored on the same server or in the same account as the application protects against a mistake, but not against a failure of that server or account. Keep at least one copy in a separate place, with separate access. Limit who can delete backups, so that one wrong command or one compromised account cannot remove the application and its safety net together.
Step 4: Test a restore every quarter
This is the step most companies skip. Once a quarter, pick one application and restore it from the backup into a separate test environment. Never overwrite the live system for a test.
Use a short checklist:
- Start the clock when you begin and write down who did it.
- Follow the written instructions exactly, and note every place where they were wrong or unclear.
- Check that the restored application starts, that you can sign in, and that recent data and uploaded files are present.
- Stop the clock when a user could work with it again.
Rotate the application each quarter so that the important ones are covered more often. Record three things in one line: the date, the time it took and what you fixed in the instructions.
A short example
Imagine a company with an order system that is critical and an internal reporting tool that is not. The order system is backed up every hour, because losing a day of orders would hurt. The reporting tool is backed up daily. Both have a second copy in a different account, and the last seven days plus four weekly copies are kept.
In the first quarterly test the team restores the order system. It takes much longer than anyone assumed, mostly because a connection setting was not written down. They add it to the instructions, and the next test is faster. The value was not in the backup itself but in finding the gap while it was cheap to fix. This example is illustrative and does not describe a real client.
What to do this week
List your three most important business applications. For each, write the one-page list from step 1 and set a backup interval from step 2. Then book a two-hour slot in the next month for the first restore test on the most important one. If a test shows the restore is slow, that is useful information, not a failure. If you are unsure which of your tools matter most, who owns an internal tool is a good place to start.
Sources
- Our related articles linked above.
- The approach described is a general working practice, not a standard; adapt it to your systems, your providers and any rules that apply to your data. The example is illustrative and does not describe a real client. No figures or client results are claimed in this article.