Why Tested Backups Matter More Than Backup Software
The question is not whether a backup job says success. The question is whether the business can recover when it matters.
Published: 12 June 2026 · Updated: 6 October 2026
Backup software is easy to buy. Recovery capability is harder to build. The difference shows up during ransomware, hardware failure, accidental deletion or the kind of quiet data corruption nobody notices until Monday morning.
A good backup strategy starts with business impact, not product features.
Backups are only useful if you can restore them
A successful backup report tells you a job completed. It does not prove the data is usable, the application will start, permissions are intact, or the recovery process is understood. Regular restore testing turns hope into evidence. The ICO expects organisations to be able to restore personal data in a timely manner after an incident, and to test that regularly (ICO).
Ransomware changes the design
Modern incidents do not politely avoid backup systems. Attackers look for backup consoles, admin credentials, file shares and cloud storage. Backups need separation, strong authentication, limited admin access and protection against deletion or encryption.
If the same compromised admin account can delete production systems and backups, the design is not resilient enough.
The 3-2-1 rule, updated for ransomware
The old discipline still holds: three copies of your data, on two different types of storage, with one held somewhere else (NCSC). What has changed is what “somewhere else” has to mean. A copy that is permanently connected and writable — a synced cloud folder, a NAS on the same network, a cloud repository the domain admin can reach — is not a safe copy, because anything that compromises the environment can reach it too. At least one copy now needs to be immutable or offline (the NCSC’s ransomware-resistant backup principles set out what that means): storage that cannot be altered or deleted for a defined period, even by an administrator.
It is also worth saying plainly: file sync is not backup. OneDrive and SharePoint will faithfully replicate an encrypted file over a good one within seconds. Sync gives you availability, not recovery.
Recovery targets need to be honest
Every business should understand two simple questions: how much data can we afford to lose, and how long can we afford to be down? Those answers shape the backup schedule, retention, replication, cloud recovery and cost.
There is no shame in choosing a pragmatic recovery target. There is a problem when nobody has chosen one and everyone assumes someone else has.
Microsoft 365 still needs thinking about
Microsoft 365 has retention and recovery features, and Microsoft now sells Microsoft 365 Backup separately, but none of that automatically means your business has the backup and restore model it expects. Mailboxes, SharePoint, OneDrive and Teams data should be reviewed against your actual retention and recovery needs.
Testing should be routine
A restore test should not feel like an annual ceremony where everyone holds their breath. It should be part of normal service management: pick systems, restore data, record results, fix issues, repeat.
In practice, a sensible testing rhythm has layers. Routinely: restore individual files and mailbox items, because that is the request you will get most often. Regularly: restore an application — database plus software — and confirm it actually starts and the data is coherent, not just present. Periodically: rebuild a whole server or recover to alternative infrastructure, timed with a stopwatch, because that number is your real recovery time and it belongs in front of management rather than in an engineer’s head.
The quiet failure modes
Most backup failures are not dramatic. The job that has been green for two years but never included the server built eighteen months ago. The agent that stopped and whose alert went to a mailbox nobody reads. Retention that turns out to be thirty days when the corruption is discovered at day forty-five. The line-of-business system that moved to the cloud, taking it quietly out of scope of the server backups — with nobody asking what backs it up now. The restore that needs credentials held by someone who left.
None of these appear on a status dashboard. All of them appear during a recovery. A backup review is largely the discipline of hunting for exactly these gaps before an incident finds them first.
When a business is down, nobody cares which logo is on the backup console. They care whether orders, files, email and systems come back.
NorthMSP builds backup and disaster recovery around tested recovery, not just backup jobs. Read more about backup and disaster recovery or arrange a free health check.
Find out whether your restores would work.
Not whether the job says success, but whether the business comes back. A free health check reviews how your backups are protected and when recovery was last tested, and puts it in writing.