Test the restore, not the backup

Most small businesses we work with can tell us they have backups. Fewer can tell us the last time anyone restored one. That gap is where a bad week starts. A backup that has never been restored is a hope with a schedule attached. It might work. It might be missing the one table that matters, or it might restore into a version of the software that no longer reads it.

When we build custom software for a client, the backup plan is part of the build, the same as the login screen or the booking flow. And the part of that plan we care about most is the restore test. This post is about how we run one and why we put it on the calendar.

Why backups fail quietly

Backups rarely fail with an alarm. They fail in ways nobody notices until the day they are needed.

The job stopped running. A password changed, a storage bucket filled up, or a server moved, and the nightly job has been failing for weeks. If the only alert goes to an inbox nobody reads, nobody knows.

It backs up the wrong thing. The database is covered, but the uploaded files are not. Or the files are covered, but the settings that tell the app how to find them are not. The restore brings back half a system.

It only restores in theory. The backup file exists, but restoring it takes a tool nobody has installed, a key nobody can find, or steps that live in the head of the person who set it up two years ago.

It is too old to help. A backup that runs once a week is fine for some data and terrible for others. If the business takes bookings all day, losing six days of them is a real problem even if the restore works perfectly.

It sits next to the original. If the backup lives on the same server, in the same account, under the same login, then the same mistake or the same break-in can take out both.

None of these show up as errors in the app. The app keeps working fine right up until the day it does not.

What a restore test looks like

A restore test is simple to describe. You take a recent backup, restore it somewhere safe that is not the live system, and check that the business could actually run from it. We do it on a schedule and write down what happened each time.

Here is the shape of it:

• Pick a real backup, not a fresh one. Use whatever the normal schedule produced, not a backup someone made by hand that morning. The point is to test what would really be there on a bad day.
• Restore into a separate place. A test copy of the app, a spare database, a staging account. Never restore over the live system to see if it works.
• Time it. Start a clock when the restore begins and stop it when someone can log in and use the app. That number is how long the business would be down, and the owner should know it.
• Check the things people use. Can a staff member log in? Are yesterday's jobs there? Do the attached photos and documents open? Do the customer notes match what is in the live system? We keep a short checklist of five to ten checks that match how the business actually uses the software.
• Write down what broke. Every test turns up something. A missing step, an expired key, a file type that did not come back. Fix it and note it, so the next test goes faster.

The first test is usually slow and a little embarrassing. That is fine. It is far better to find the missing step on a quiet Tuesday than during an outage with customers calling.

Decide how much you can afford to lose

Before picking a backup schedule, it helps to answer two plain questions with the owner.

How much recent work could the business lose and still be fine? For a shop that books most of its jobs in the morning, losing a day of bookings might mean a lot of phone calls and some angry customers. For a reporting tool that updates once a week, losing a day barely matters. The answer sets how often the backup runs.

How long could the business run without the system? Some teams can work from paper and a shared phone for a day. Others stop cold the moment the schedule disappears. The answer sets how fast the restore has to be, and the restore test tells you whether you actually hit it.

These answers are different for different parts of the same system. Customer records and bookings usually need tight coverage. Old reports and logs can wait. Writing that down keeps the backup plan from being either too thin where it matters or expensive where it does not.

Keep the plan where the next person can find it

A restore that only one person knows how to do is a single point of failure, the same as a server with no backup. So we write the steps down in plain language and keep them somewhere the client controls, not only in our own notes.

The written plan covers:

• Where the backups live and how often they run.
• Who has access to them, and how that access is stored.
• The exact steps to restore, in order, including any keys or tools needed.
• The checklist used to confirm the restore worked.
• The date and result of the last test.

We also make sure at least one copy of the backups lives outside the main account, under separate access. That way a deleted account, a billing lapse, or a stolen password on the main system does not reach the copies too.

And the alert for a failed backup goes somewhere a person actually looks, with a named owner. A failed job that pings a shared inbox once is easy to miss. A failed job that shows up in the team's daily check, or sends a text to the person responsible, gets fixed.

Put the first test on the calendar

If you run software your business depends on, pick a date in the next month and restore a backup into a test copy. Time it. Check that people can log in and that yesterday's work is there. Write down every step that was harder than it should have been.

Then pick the next date. A few times a year is enough for most small teams, plus one after any big change to the system, like a move to a new server or a major update. It is a few hours of work each time, and it turns "we have backups" into "we know we can come back," which is the only version that helps when something goes wrong.