A backup job that says "completed" tells you one thing: something was copied somewhere. It does not tell you whether the copy is complete, whether it can be opened, or whether anyone knows how to put it back. The only way to know is to try.
Why backups fail when you need them
Backups rarely fail loudly. They fail quietly, months before anyone notices. The most common reasons we see:
The job stopped
A password changed, a disk filled up or a server was replaced, and the nightly job has not run since. Nobody was told.
Only part was copied
The database was backed up but the uploaded files were not, or the other way round. The system comes back with holes in it.
The copy cannot be opened
The encryption key was lost, the file is damaged, or it needs a software version you no longer have.
Nobody knows the steps
The person who set it up has left. Restoring takes days of guessing instead of an hour.
The 3-2-1 rule, in plain words
The 3-2-1 rule is the simplest way to make sure one bad day cannot take every copy with it:
| 3copies | 2kinds of storage | 1copy elsewhere | |
|---|---|---|---|
| What it means | Keep three copies of important data: the live system and two backups. | Store them on at least two different kinds of storage, for example the server's disk and cloud storage. | Keep at least one copy in a different place, away from the server and the office. |
| What it protects against | One copy being damaged or deleted. | One type of storage failing or being encrypted by ransomware. | Fire, theft, or a whole provider or building being unavailable. |
Many teams now add one more idea: at least one copy that cannot be changed or deleted for a set time (often called immutable or object lock storage). If ransomware or a stolen password reaches your servers, that copy is still safe.
A simple restore test anyone can run
A restore test does not have to touch your live system. It brings a backup back somewhere safe and checks that what came back is complete and usable.
Pick the backup
Take the most recent backup of one important system, for example last night's database backup.
Restore it somewhere safe
Restore it to a separate test server or a temporary location — never over the live system.
Check it, not just open it
Count records, open a recent invoice or order, and compare with the live system. If you can, start the application on the restored copy.
Write down the time it took
How long from "start" to "usable"? That number tells you how long a real recovery would take.
Record the result
Date, which backup, what was checked, who did it, and what went wrong. Auditors and insurers often ask for exactly this.
How often should you test?
There is no single right answer, but a sensible starting point for most small and mid-sized businesses is:
| Examplessystems | Test a restoreat least | Check the job ranat least | |
|---|---|---|---|
| Business-critical | ERP, accounting, customer database | Every 3 months, and after any big change | Every day |
| Important | Email archive, file server, website | Every 6 months | Every day |
| Everything else | Old projects, archives | Once a year | Every week |
Also test after anything that changes how backups work: a new server, a new version of the database, a new storage provider or a new encryption key.
A monthly backup checklist
Every job ran
Check that each backup job ran on every scheduled day this month, not just the last one.
Sizes look normal
A backup that is suddenly much smaller than usual is a warning sign.
One copy is off-site
Confirm the off-site copy exists and is recent.
Keys are safe
The encryption key is stored somewhere you can reach even if the server is gone, and more than one trusted person knows where.
A restore test is due?
If the last test was longer ago than your plan says, book the next one now.
Making it automatic
You can do all of this with a spreadsheet and discipline. What usually goes wrong is the discipline. A monitoring tool helps by doing the boring part: it tells you when a job did not run, and reminds you when a restore test is due.
That is exactly why we built TBS Infrastructure to show backup status and restore-test results separately: backups go to your own storage, encrypted with your own key, and a backup only counts as proven once a restore test has brought it back and checked it. Scheduled jobs can send a heartbeat, so a missed run becomes an alert instead of a surprise.
Want to know if your backups would really restore?
We can look at your current setup and run a first restore test with you.
This article is general guidance based on our own experience as of 27 Oct 2026. It is not legal or compliance advice; requirements differ by industry and country.