Most businesses have some form of backup. A NAS on the network. OneDrive sync. An automated job that runs at 2am. When we ask clients if they have backup, the answer is almost always yes.
When we ask if they've ever tested their backup — whether they've actually verified that they can restore from it — the answer is almost always no.
And when we ask what their plan is for getting the business back online after a ransomware attack or server failure, the silence that follows tells us everything we need to know.
Backup and Disaster Recovery Are Different Things
A backup is a copy of your data. Disaster recovery is the plan, process, and infrastructure for restoring operations after a disruptive event. Backup is an input to disaster recovery. It is not disaster recovery itself.
The distinction matters enormously in practice. You can have excellent backup coverage and still face days of downtime after an incident — because the backup exists but no one knows how to use it, because the restore process takes 48 hours, because the backup was also encrypted in the ransomware attack, or because critical systems depend on configurations that were never backed up.
The Most Common Backup Failures We See
Backup jobs that fail silently
Backup jobs fail. Drives fill up. Authentication tokens expire. Network paths change. Without active monitoring of backup job status, a backup that stopped running six weeks ago looks exactly like a backup that ran last night — until you need it.
We've walked into environments where the "backup" hadn't successfully completed in months. Nobody knew because nobody was checking.
Backups that are on the same network as the systems they protect
Ransomware specifically targets backup systems. Attackers know that a business with clean backups doesn't need to pay the ransom, so destroying or encrypting the backup is a priority. A NAS on the same network segment as your servers, accessible with the same credentials, is not a ransomware-resilient backup.
Effective backup requires at least one copy that is either air-gapped (physically disconnected), immutable (cryptographically protected from modification or deletion), or in a cloud environment with separate access credentials that don't exist anywhere in your primary environment.
Microsoft 365 and Google Workspace aren't backed up
This is the misconception that costs businesses data most often. Microsoft and Google provide infrastructure reliability — your data won't be lost because their servers fail. But they do not provide comprehensive backup. Deleted emails and files have limited retention windows. Ransomware that syncs encrypted files to OneDrive overwrites your clean copies. Accidental or malicious deletion can result in permanent data loss.
Microsoft's own Services Agreement recommends using third-party backup for Microsoft 365 data. Most businesses don't do this until after they've lost something.
The restore has never been tested
The only way to know your backup works is to restore from it. Not check that the job completed — actually restore files, databases, and systems from the backup and verify they're functional. This sounds obvious. Most businesses have never done it.
A backup you've never tested is not a backup. It's a hypothesis.
What a Real Disaster Recovery Plan Looks Like
A business continuity and disaster recovery (BCDR) plan covers four things that backup alone doesn't address:
Recovery Time Objective (RTO)
How long can your business be down before the impact becomes unacceptable? This could be 4 hours, 24 hours, or several days depending on your industry and operations. Your RTO drives what kind of recovery infrastructure you need. If you can't afford to be down for more than 4 hours, you need different backup technology than a business that can tolerate a 48-hour recovery window.
Recovery Point Objective (RPO)
How much data can you afford to lose? If your backup runs nightly and an attack happens at 5pm, you could lose a full day of transactions. If that's unacceptable, you need more frequent backup — or real-time replication for critical systems.
Documented recovery procedures
Who does what, in what order, when something goes wrong? The people responsible for recovery shouldn't be figuring out the process for the first time during an actual incident. Written runbooks, tested at least annually, are the difference between a 4-hour recovery and a 4-day one.
Communication plan
Who gets notified when a significant incident occurs? In what order? What do you tell employees, clients, and vendors while systems are down? What are your regulatory notification obligations? These questions have answers — and the answers should be written down before you need them.
The Backup Stack That Actually Protects You
For most small and midsize businesses, a complete backup and DR setup includes:
- Endpoint and server backup with daily jobs, monitored status, and tested recovery
- Immutable cloud backup — at least one copy that can't be deleted or encrypted, even by ransomware with admin-level access
- Microsoft 365 backup via a third-party solution (we use Cove) covering Exchange Online, SharePoint, OneDrive, and Teams
- Documented RTO and RPO that match your business requirements
- Written recovery runbooks tested at least annually
- Backup job monitoring — someone is alerted immediately when a job fails, not three weeks later when you need the data
The Honest Question to Ask
If ransomware hit your environment tonight, how long would it take to get back to normal operations? If you don't have a confident, specific answer — with a tested backup and a written recovery plan behind it — that's the gap that needs to close before you need it.