Twelve questions on the difference between having backups and being able to use them. Built for small businesses across Chester County PA, northern Delaware, and northern Maryland, though the questions apply anywhere.
12 questions, about two minutes. Everything runs in your browser and nothing you enter is sent anywhere.
Ordered by what each one costs you at the moment you actually need the backup, not by how easy it is to sort out.
The system that turns out not to be backed up is almost never the obvious one. It is the industry-specific application somebody installed years ago, or the spreadsheet the whole business quietly depends on that lives on one desktop.
Try this: Write down the five systems you could least do without. Then ask whoever handles backups to confirm each one, by name, is included. It is the fifth one that usually is not.
What fixing it involves: A written list of what must survive, checked against what is actually being backed up. That reconciliation is the work, and it is usually an afternoon.
If the contents of the backup are unknown, then so is the answer to whether you could recover, and you will discover the real answer at the point where it is too late to change it. This is not a documentation problem, it is the whole question.
Try this: Ask for a list of exactly what is backed up, produced today rather than from memory. How long that takes, and whether it can be produced at all, is your answer.
What fixing it involves: Establish what is covered before changing anything else. Every other decision here depends on knowing that, and it is usually a short piece of work with uncomfortable results.
Daily is reasonable for most small businesses, and it is worth being clear about what it means: a failure late in the afternoon loses everything since the previous night. For a business that invoices, books, or records all day, that can be a lot of re-keying.
Try this: Ask what the business did yesterday that would have to be done again. That is the real cost of the gap, and it is often larger than expected.
What fixing it involves: Either accept it deliberately, which is a perfectly good answer, or increase the frequency for the one or two systems where a day actually hurts.
A week of lost work is not an inconvenience, it is a project to reconstruct, and some of it cannot be reconstructed at all. Where nobody knows the frequency, it is usually because nobody has looked at the backup since it was set up.
Try this: Find the date and time of the most recent successful backup. Not the schedule, the actual last one. The gap between those two is the finding.
What fixing it involves: Decide what you can afford to lose first, then set the frequency to match. Doing it the other way round is how businesses end up with a schedule nobody chose.
Without this number, the frequency is whatever the software suggested on the day it was installed. That might be right. Nobody has checked, and it is the only figure that tells you whether it is.
Try this: Ask two people what they think would happen if the business lost a day of work. Different answers mean the decision has not been made.
What fixing it involves: One short conversation, written down. It costs nothing and it is the number every other backup decision follows from.
A backup in the same room as the server it protects covers you against one thing: that server failing. It does not cover a fire, a flood, a burst pipe, or a theft, all of which take the original and the backup together. The whole point of a backup is that it is somewhere else.
Try this: Stand in the room where the server is. Everything you can see from there is a single event away from being gone at the same time.
What fixing it involves: A cloud copy or a rotated drive stored elsewhere. Cloud backup for a small business is a modest monthly cost and it is the single most important gap here to close.
Worth resolving quickly, because it is the difference between a bad week and a business that does not reopen. Not knowing usually means it was set up once and never reviewed.
Try this: Ask where the backup physically is. If the answer is a device in the building, or nobody can say, you have your answer.
What fixing it involves: Confirm what exists today, then add an offsite copy if there is not one. This is the cheapest insurance in this whole list.
Modern ransomware looks for backups first and destroys them before encrypting anything, because that is what turns a recoverable incident into a payment. A backup drive plugged into the server, or a network share the server can write to, is part of the attack surface rather than protection from it.
Try this: Ask whether the backup location can be written to by an account on your main network. If it can, ransomware running with those rights can delete it.
What fixing it involves: One copy that cannot be modified: immutable cloud storage, or a drive that is physically disconnected between backups. This is the specific control that decides whether ransomware is expensive or terminal.
Most small business backups were designed against hardware failure, which was the right thing to design against for decades. Ransomware changed what a backup has to survive, and setups configured before that shift usually have not been revisited.
Try this: Ask one question: is there a copy of our data that our own administrator account cannot delete? Hesitation is the answer.
What fixing it involves: Confirm what protection exists now, then add an immutable or offline copy if there is none. It is usually a setting on backup software you already own.
Backups drift. New systems get added and never included, folders move, a job starts failing and the alert goes to someone who has left. A test that passed last year says nothing about the state of things this week.
Try this: Ask for a specific file from about a month ago, restored today, opened in front of you. Time how long the whole thing takes.
What fixing it involves: A quarterly restore test with the result written down. Fifteen minutes, and it converts an assumption into a fact.
Until a restore has been done, you do not have a backup, you have a backup job. Those are different things, and the difference only becomes visible at the moment you can least afford to find out. This is the most common serious finding I encounter.
Try this: Ask to watch a file come back from backup, today. The reaction to the request usually tells you the answer before the test does.
What fixing it involves: One test restore now, to establish where you actually stand, then a schedule. If it fails, far better to find out on a quiet Tuesday.
These are different operations with different failure modes. Pulling back a deleted spreadsheet says nothing about whether a server can be rebuilt from the same backup, and rebuilding is what an actual disaster requires. Missing drivers, licence keys, and configuration surface only in the second kind.
Try this: Ask what the plan is if the main server does not come back on at all. If the answer describes restoring files onto a replacement, ask where the replacement and its configuration come from.
What fixing it involves: A full recovery test, ideally onto spare or virtual hardware so nothing live is at risk. It usually surfaces two or three things nobody knew were needed.
The first attempt at a whole-system restore is always the one that finds the problems. Doing it for the first time during a real incident means finding them while the business is stopped and everyone is watching.
Try this: Ask how long a full rebuild would take and how confident the answer is. An estimate given without hesitation and without evidence is worth very little.
What fixing it involves: Test it once, properly, and record what it took. Everything about the recovery plan improves after the first real attempt.
Untested estimates are consistently optimistic, and usually by a lot, because they count the restore and not the rest: getting hardware, rebuilding configuration, re-establishing connections, and doing it all while the phone is ringing.
Try this: Take the estimate and ask what it includes. If it does not include sourcing replacement hardware, it is describing part of the job.
What fixing it involves: Test it once and record the real number. It is also the input the downtime calculator needs, and the figure that usually settles the budget conversation.
This is the number everything else depends on. Without it you cannot judge whether your current arrangement is adequate, cannot plan around an outage, and cannot answer the question a client or an insurer will ask first.
Try this: Ask the question plainly: if the main server died tonight, when are we working again? Any answer that is not a number with reasoning behind it is a guess.
What fixing it involves: Work out what a realistic recovery looks like end to end, then decide whether the answer is acceptable. If it is not, that is a design problem rather than a backup problem.
This is the mechanism behind almost every backup that turns out to be months old. The emails were sent faithfully, to an address nobody watches, or into a folder rule that files them away. The system did its job and the outcome was the same as having no alerting at all.
Try this: Find the last backup failure email anyone received. If nobody can find one, either nothing has failed in months, or the alerts are not arriving where anyone will see them.
What fixing it involves: Point alerts at a person by name rather than a shared address, and make an unanswered failure something that escalates. Monitoring is only worth anything if somebody is at the other end.
Without alerting, the state of the backup is unknown between the day it was set up and the day you need it. A job that stopped six months ago looks exactly the same from the outside as one that ran last night.
Try this: Check the date of the last successful backup right now. Whatever that date is, it is the honest answer to what you have.
What fixing it involves: Turn on alerting and send it to a person. Nearly every backup product includes this and it is very often left switched off.
Backups are the one system that can fail completely without any visible symptom. Everything else announces itself. This does not, which is exactly why it needs looking at deliberately rather than when something reminds you.
Try this: Open the backup console today and read the date of the last successful run. That single number is the most useful thing in this entire check.
What fixing it involves: A monthly glance, or reporting that arrives without being asked for. The second is better because it does not depend on anyone remembering.
This is the most common wrong assumption I find, and it is a completely reasonable one to have made. The retention built into these platforms is short and designed for accidents, not for a compromised account quietly deleting a year of mail, or a dispute that surfaces months later.
Try this: Ask what happens if a mailbox is deleted today and nobody notices for four months. Then look up your plan’s actual retention period and compare the two numbers.
What fixing it involves: Independent cloud-to-cloud backup, priced per mailbox and typically a small monthly cost. One of the cheapest gaps in this whole check to close.
Disasters are inconsiderate about timing. If the recovery lives in one person’s memory, then your continuity plan quietly includes an assumption that they answer the phone, are not on a plane, and still work here.
Try this: Ask that person to write down what someone else would need to do. Whether they can, and how long it takes them, is the finding.
What fixing it involves: A short written recovery procedure: what to restore, in what order, from where, and what credentials are needed. Two pages is usually enough, and it is worth more than most of the software.
This is a single point of failure sitting on top of every other control here. The backups can be perfect and it makes no difference if the only person who knows how to use them is unreachable on the day.
Try this: Ask what would happen if that person were unavailable for a fortnight during an incident. The silence is usually the answer.
What fixing it involves: Documentation first, then a second person walked through it once. The walkthrough matters, because documentation nobody has followed is usually missing the step everyone assumed.
That is rare, and it says somebody has thought about this properly. The one thing worth adding is that this reflects what you told it. If it has been a while since anyone confirmed the answers by actually restoring something, that is the useful next step rather than any new control.
I will go through your result and tell you which gaps genuinely matter for a business your size, and which are fine to leave. The most useful thing is usually a single test restore, and that is a short conversation rather than a project.
Book a 15 minute callI will send your score and the full list of findings as a document you can keep, forward to your provider, or put in front of your insurer. One email, and I do not add you to a list.
It assumes you run the business rather than the network. If you can answer questions about how your office works, you can complete it.
Backup software reports on whether it ran. That is not the same question as whether what it produced is complete, current, reachable, and usable by someone who is not the person who set it up. Almost every business that finds out the difference finds out on the worst possible morning.
A job that has been failing silently for months. A system nobody thought to include. A restore that works but takes nine days. Backups on the same network as everything else, encrypted alongside it. None of these are exotic and all of them are invisible until you need the backup.
Nearly everything else in security lowers the chance of an incident. This one decides what happens after. A business that can recover has an expensive week. A business that cannot may not have a business.
The IT Health Check asks whether you could recover and when you last tested. This asks whether a copy exists that ransomware on your network cannot reach, whether a whole system has ever been restored rather than one file, and whether anyone would notice a month of failures.
Each answer carries a weight based on what it costs you at the moment you need the backup. Not knowing what is covered and never having tested a restore are not the same size of question as whether the schedule is daily or hourly.
| What is missing | Weight | Example from this check |
|---|---|---|
| Critical control missing | 15 points | No copy outside the building, backups reachable by ransomware, or never restore-tested |
| High-risk control missing | 10 points | No cloud platform backup, no alerting on failures, or recovery that depends on one person |
| Moderate gap | 5 points | A daily rather than hourly schedule, or a recovery time nobody has measured |
It is scaled, not subtracted. There are 130 points of possible weight here, so the score is your weighted total expressed against the worst case rather than counted down from 100.
Four questions can cap the rating, more than any other check here. Not knowing what is covered, having no copy outside the building, backups that ransomware could reach, and never having tested a restore each mean, on their own, that you do not have a backup you can rely on. Any one of them holds the overall rating at "needs attention" or lower, and two hold it at "high risk", whatever the number says.
It asks, it does not verify. I cannot see your backup software from here, and the gap between what people believe about their backups and what is actually configured is the widest gap in this entire set of tools. The only real answer to most of these is a test restore in front of you, and that is a different piece of work from a questionnaire.
The health check asks whether you could recover and when you last tested. This asks the mechanics behind those answers: whether a copy exists that ransomware on your network could not reach, whether a whole system has ever been restored rather than one file, how long a real recovery would take, and whether anyone would notice a month of silent failures. Run the health check for the broad picture, this one if backup is the thing keeping you up.
A copy that cannot be changed or deleted for a set period, even by someone holding full administrator credentials. It matters because ransomware now looks for backups first and destroys them before encrypting anything, using the admin rights it has taken. A copy it cannot modify is what stops that working. Offline media achieves the same thing by being physically disconnected.
It covers one thing well, which is a server failing, and that is worth having. It does not cover fire, flood, theft, or ransomware, because all four take the NAS and the server together. A NAS is a good first copy and a poor only copy.
As often as the amount of work you can afford to lose, which is why one of the questions here asks whether anyone has decided that. For most small businesses daily is reasonable and deliberate; for a business that invoices or books all day, losing an afternoon can be a genuinely bad day. The point is to choose the number rather than inherit it.
Yes, and it is the most common serious finding I encounter. Backup software reports on whether the job ran, which is a different question from whether what it produced is complete and usable. Until a restore has actually been done, what you have is a backup job rather than a backup. One test tells you which.
Free, and the whole result appears without entering anything. Email is only for the written version, which is optional. Nothing you enter leaves your browser.
A test restore, before changing anything. It costs nothing, it takes under an hour, and it establishes which of the answers above are true. Buying or reconfiguring anything before you know that is solving a problem you have not confirmed you have.
All free, all a couple of minutes, and none of them ask for anything before showing you the answer.
Build a checklist for a departure in the order the steps actually need doing.
Start itThirteen questions on the controls that decide whether a bad day stays a bad day.
Start itPut a number on what an outage costs you, using your figures rather than anyone else’s.
Start itI will walk through what came back, tell you which items genuinely need attention and which can wait, and you are under no obligation after it.
Free, no obligation, and you talk directly with a senior engineer.