Almost every business I talk to says it has backups. Far fewer can say when they last restored one, how long it took, and whether everything came back. The difference matters, because a backup only proves its worth on the worst day the business has: the server that will not start, the update that corrupted the database, the employee who deleted the wrong folder, the ransomware note on the screen.
On that day, nobody asks whether a backup exists. They ask how long until the shop is selling again, and how much was lost. This article is about being able to answer both questions in advance: what to back up, how often, where to keep it, and above all how to test that it actually comes back.
Why backups fail without anyone noticing
Backups fail quietly. A job that has stopped running sends no e-mail. A backup that has grown too large for its destination stops halfway and still looks like a file. A database copied while it was being written to can be unreadable. A password for the backup storage changes and nobody updates the script. Each of these is discovered at the same moment: when the backup is needed.
The only way to know a backup works is to restore it, regularly, on purpose, while nothing is on fire. Until you have done that, what you have is a hope.
What to back up
Start by listing what the business would actually need to start again on a clean server. It is usually more than the database:
- The database: orders, customers, products, invoices, users.
- Uploaded files: product photos, documents, invoices stored as files, anything customers or staff uploaded.
- Configuration: the settings that are not in the code, including the environment variables and secrets the application needs to start.
- The code itself, or at least the exact version that is running, so you can rebuild the same thing.
- Anything outside the server that the business depends on: DNS records, e-mail settings, payment and courier account details.
A backup of the database alone restores a shop with no product photos. A backup without the configuration restores an application that cannot connect to anything.
The two numbers that matter
Two numbers decide how a backup should be set up, and they are business decisions, not technical ones:
- How much can you afford to lose? If the last backup was last night and the server fails at five in the afternoon, a day's orders are gone. For some businesses that is acceptable, for a busy shop it is not.
- How long can you afford to be down? Restoring a large database and its files onto a new server takes time. Hours may be fine for an internal tool and unacceptable for a shop in December.
Answer both honestly, then design the backups to meet them. More frequent backups reduce what you lose. A practised restore, and a server that can be prepared quickly, reduce how long you are down.
How often, and how many
How often to back up follows from the first number. A database that changes all day needs more than a nightly copy if losing a day hurts; many databases can keep a continuous log of changes that lets you restore to a point in time, not just to last night. Uploaded files change less often and can usually be copied less frequently, as long as new files are included.
Keep more than one generation. A single backup that is overwritten every night is useless if the problem was introduced two days ago and has been copied faithfully into every backup since. A common pattern is daily copies for a couple of weeks, weekly copies for a few months, and monthly copies for longer, adjusted to what the business and the law require.
Where to keep it
A backup on the same server as the data protects against almost nothing. If the server fails, is compromised or is deleted, the backup goes with it. At minimum:
- Keep a copy somewhere else: a different provider or at least a different location from the server.
- Keep at least one copy that the server itself cannot change or delete. If an attacker gets control of the server, the first thing they will try is the backups.
- Encrypt backups that leave the server, and keep the key somewhere you can reach when the server is gone.
That last point catches many people. An encrypted backup whose key lived only on the failed server is as good as no backup.
Test the restore, not the backup
A restore test means taking a recent backup and bringing it back on a separate, clean machine, exactly as you would after a disaster, then checking the result. Not reading the backup's file list, not checking that the file is large: restoring it and using it.
A useful test checks:
- That the application starts on the restored data.
- That recent orders, customers and files are there, up to the time the backup was taken.
- That logging in, searching and placing a test order work.
- How long the whole restore took, from "we need it" to "it works".
Write down the time and anything that was missing or surprising. The first test almost always finds something: a folder that was never included, a step nobody had written down, a password nobody could find.
How often to test
Restore tests are not a one-off. Systems change: a new folder of uploads, a new service, a bigger database. A restore that worked a year ago says little about today. A test every few months is a reasonable rhythm for most small businesses, and one after any large change to how the system is built or hosted.
It helps to make the test boring and routine, the same steps every time, written down, with a short note of the result.
Write it down while you do it
The restore test is also the moment to write the instructions you will want on the bad day: where the backups are, how to get to them, which key decrypts them, the order of the steps, and who to call. Written by someone who has just done it, not reconstructed from memory under pressure.
Keep that note somewhere that does not depend on the system it describes. A restore guide stored only on the server you need to restore is not much help.
Even with good backups, the most common real failure is the job that quietly stopped. Make it impossible to miss:
- Have each backup report success, not just failure. A missing success message is the alarm.
- Check the size of each backup against the last one. A backup that suddenly shrinks has usually stopped including something.
- Have someone look at the backup report on a fixed day, not "when there is time".
Backups contain personal data too
A backup of a shop or a booking system is full of personal data: names, addresses, phone numbers, order histories. It deserves the same care as the live system. Know where every copy is, who can reach it, and how long it is kept, and keep it no longer than you need.
It also helps to decide in advance what happens when you restore an old backup after a customer has asked to be deleted. The usual answer is a short list of deletions to re-apply after any restore, so a restore does not quietly bring back data you promised to remove.
Not every problem needs a full restore
It is worth knowing which kind of problem you are preparing for, because they need different things:
- The whole server is gone: you need everything, on a new machine, as fast as possible.
- One thing was deleted or damaged by mistake, a product, an order, a folder of images: you need to pull that one thing out of an older backup without rolling the whole business back.
- Something went wrong slowly, a bug that has been corrupting data for a week: you need an older generation, and a way to compare it with today.
A good restore test exercises at least the first two. Bringing back one deleted order without disturbing the rest is a different skill from rebuilding the server, and it is the one you will need far more often.
What lives outside your server
Some things a business depends on are not on its server at all and are easy to forget: the DNS settings for the domain, the e-mail provider's configuration, the payment provider and courier accounts, the app store accounts for a mobile app. Write down where each lives and who has access. Losing access to the domain's DNS can take a business offline as surely as losing its server, and it has no backup file.
A checklist
Before you rely on your backups, you should be able to answer yes to each of these:
- We know how much data we can afford to lose, and how long we can afford to be down.
- The database, uploaded files, configuration and code are all backed up.
- There is more than one generation, going back further than a single night.
- At least one copy is off the server, and the server cannot delete it.
- Backups that leave the server are encrypted, and the key is stored separately.
- We get a message when a backup succeeds, and notice when it does not arrive.
- We restored a backup onto a clean machine within the last few months.
- We know how long that restore took.
- The restore steps are written down somewhere that does not depend on the server.
Where to start
If you have never tested a restore, do it this month. Pick a quiet day, take last night's backup, and try to bring the business back on a spare machine without touching the live one. Whatever goes wrong in that test is something that would have gone wrong on the real day, at a much worse time, and now you can fix it calmly.
Not sure your backups would come back?
Discuss your projectTell me what your system runs on and when you last restored it.