Most businesses can point at a backup. Fewer can say, with a straight face, how they would recover. Those are different capabilities.
A green job in a console means a copy was attempted. Recovery readiness means you know what matters, the copy is the right sort of copy, someone is told when a job fails, and you have practised getting the business back. Backup and recovery as an operating discipline is the second of those.
Start with what would actually stop the business
List the systems and data without which you cannot trade, invoice, speak to customers, or pay people. Be honest. The file share that everyone uses might matter more than a server that has not been opened in a year.
Not everything needs the same treatment. A public marketing site and the finance system are not the same recovery problem. Trying to back up “everything the same way” is how you pay for copies you never test and still miss the mailbox that runs the company.
Scope is a design choice
Scope answers: what is included, what is excluded, and why. Typical places work lives now:
- Microsoft 365 — Exchange Online, OneDrive, SharePoint, and sometimes Teams. Platform retention is not automatically an independent backup.
- Cloud workloads — virtual machines, databases, storage accounts. Snapshots and application-aware copies are not interchangeable.
- Servers still in a cupboard or a rack — including the ones everyone assumes are “just a leftover”.
- NAS and shared storage, where a lot of small businesses still keep working files.
- Laptops, if important data never reaches a shared location. The plan should prefer putting the data in the right place rather than heroically imaging every device.
“There is no single architecture that every organisation requires. A ten-person professional firm and a workshop with a specialist line-of-business server will not look the same. They should both be able to explain theirs.”
Retention, access and security of the copies
Retention is how long copies are kept, and whether you can go back far enough to survive delayed ransomware or a quiet file deletion. Longer is not automatically better: it costs, and it can keep data you no longer wanted to hold.
The copies themselves need access control. A backup that the same compromised administrator account can encrypt or delete is a thinner comfort than it looks. Separate credentials, limited access, and copies that cannot be quietly rewritten are design issues, not slogans.
Ransomware is the scenario that exposes wishful backups. Offline or immutable copies, depending on what you run, exist because online-only copies can be attacked with the live systems. This is not a product recommendation. It is a question you should be able to answer.
Monitoring failed jobs is part of the backup
An unwatched backup is a hobby. Someone has to be told when a job fails, when a volume grows unexpectedly, or when a new system was never added to the job after a migration.
Alerts that nobody reads do not count. Neither does a quarterly glance at a dashboard. If keeping the business running depends on a restore, failed jobs belong in the same operational pile as a downed internet link.
Recovery objectives are conversation, not a guarantee
How much data can you afford to lose (a few minutes, a few hours, a day)? How long can you work around a system before it must be back? Those questions produce recovery point and recovery time objectives in larger organisations. In a small business they are still the right questions, even if the answers are “the previous night” and “the same day if we are lucky”.
Do not treat a website article as a commitment. Nobody can guarantee a restore from outside your environment. Hardware fails in new ways. Microsoft has its own service boundaries. An ISP outage can sit in the path. The honest output is a documented intent and a tested method, not a promise.
Documentation, responsibilities and testing
Write down what is backed up, where the console lives, who can restore, which vendor is in the path, and what “good” looks like for a test. The Radius Standard treats data and backup as a managed area for this reason: copies without ownership are decoration.
Responsibilities should be explicit. Who notices a failed job? Who is allowed to restore production data? Who talks to Microsoft or the backup vendor? Who tells the business that today is a recovery day?
Testing is the part that gets postponed. Restore a mailbox. Restore a folder. Restore a server to an isolated place if you can. Time it. Note what was missing from the documentation. A test that only confirms the job is still green is not a recovery test.
Protecting the business includes this work. Encryption and MFA do not replace the ability to get files back.
Questions that show whether a plan exists
What was recovered last, and when? What is not backed up, on purpose? If ransomware encrypted the live files tonight, which copy would you use, and who would do it? If the answer is a pause, you have a backup product. You do not yet have a plan.
A Technology Review can surface that distinction without pretending a questionnaire is a restore test.