Data Backup and Disaster Recovery: How to Make Sure Your Business Can Actually Come Back

Most small businesses do not discover the state of their backups on a calm Tuesday morning. They discover it at 4:45 p.m. on a Friday, when a server refuses to boot, a shared drive is suddenly full of encrypted gibberish, or someone realizes the folder they deleted three weeks ago was the only copy. That is the worst possible moment to learn that the backup job has been quietly failing since spring — and it is exactly the moment when a real data backup and disaster recovery plan pays for every dollar it ever cost.

We work with small and mid-sized companies across Orange County, and the pattern is remarkably consistent: nearly everyone has something that they call a backup. Very few have a plan they have actually tested. This guide walks through the difference — what to back up, how often, where to keep it, and how to prove the whole thing works before you need it. No fear-mongering, no vendor pitch, just the practical version.

Backup and Disaster Recovery Are Two Different Things

People use these terms interchangeably, and that confusion causes real damage. They solve different problems and they fail in different ways.

Backup answers the question: can I get this file back? It is about copies of data. Someone overwrote a spreadsheet, an employee deleted a shared folder, a database table got corrupted. You go to a copy, you restore it, you move on.

Disaster recovery answers a much bigger question: can we operate? It is about restoring business function, not just files. If your primary systems disappeared this afternoon — server room flood, ransomware across the network, a cloud tenant locked out — how does the company keep taking orders, answering phones, invoicing, and paying people?

You can have excellent backups and no disaster recovery capability at all. We have seen companies with perfectly good file copies sitting in cold storage that still lost eight business days, because nobody had thought about the hardware, credentials, and sequencing needed to actually turn those copies back into a working environment.

A backup is a copy. Disaster recovery is a plan. You need both, and the plan is the part almost everyone skips.

Start With Two Numbers: RPO and RTO

Before you evaluate a single product, decide what you are actually buying. Two numbers drive every other decision in data backup and disaster recovery, and both of them are business decisions, not technical ones.

RPO — Recovery Point Objective. How much data can you afford to lose, measured in time? If your backups run nightly at 2 a.m. and the system dies at 6 p.m., you have lost a full business day of work. For some companies that is a nuisance. For a business doing transactional work all day, re-entering a day of orders may not even be possible.

RTO — Recovery Time Objective. How long can you be down before the damage becomes serious? Not “how long would we prefer” — how long before you are losing customers, missing contractual obligations, or sending staff home.

Write both numbers down honestly, per system. They will not be the same everywhere. Here is the kind of tiering we typically end up with:

System	Typical RPO	Typical RTO	Why
Accounting / ERP	Minutes to 1 hour	Hours	Money moves through it; gaps are hard to reconstruct
CRM / sales pipeline	1–4 hours	Same day	Lost activity means lost deals
Email & collaboration	Near-continuous	Hours	It is the company’s nervous system
Website / ecommerce	Hours to daily	Hours	Downtime is directly visible to customers
File shares / archives	Daily	Days	Large, mostly static, rarely urgent

The moment you put real numbers on paper, budget conversations get easier. “We need better backups” is a vague ask that competes with everything else. “We can tolerate four hours of downtime on the order system and we currently cannot recover it in under three days” is a decision.

The 3-2-1 Rule, and Why It Now Needs a Fourth Number

The old standard was 3-2-1: keep three copies of your data, on two different media types, with one copy offsite. It is still a good baseline. But it was written before ransomware crews learned to hunt for backup repositories specifically — because encrypting the backups is what turns an incident into a payday.

So the modern version adds a fourth element: one copy that is immutable or offline. Immutable means the storage itself refuses deletion or modification for a set retention window, even if someone presents valid administrator credentials. That property is what stops an attacker with domain admin from erasing your recovery path.

• Three copies — production, plus at least two backups.
• Two media or platforms — do not let a single vendor account or single device be the only thing standing between you and total loss.
• One offsite — geographically separate from the office. Fire, flood, and theft do not respect a good backup schedule.
• One immutable or air-gapped — cannot be deleted by a compromised admin account.

The Backup Gap Nobody Expects: Your Cloud Apps

This is the single most common blind spot we find, and it deserves its own section. Many business owners assume that because their email, files, and CRM live in the cloud, backup is handled. It largely is not — at least not in the way you are imagining.

Major providers operate under a shared responsibility model. They are responsible for keeping the service running and the infrastructure resilient. You are generally responsible for your data — including recovering from your own mistakes. Retention policies exist, but they are short, they vary by license tier, and they are designed for accidental deletion, not for a year-old record you need for a legal dispute or a mass deletion nobody noticed for six weeks.

Places this bites companies regularly:

• An employee leaves, the account is deleted to save a license fee, and their mailbox and personal drive go with it after the grace period.
• A sync client on an infected laptop happily replicates encrypted files up to the cloud, overwriting the good versions.
• A bad data import or a rogue automation overwrites thousands of CRM records, and version history does not go back far enough to help.
• A third-party app with broad API permissions is compromised and mass-deletes records through entirely legitimate calls.

If your business runs on Microsoft 365, Google Workspace, a hosted CRM, or an ecommerce platform, add a dedicated third-party backup for those tenants. It is one of the least expensive and highest-leverage moves in the entire data backup and disaster recovery conversation. Our post on choosing between Microsoft 365 and Google Workspace covers the platform decision itself; whichever you land on, the backup question stays the same.

An Untested Backup Is a Rumor

We will be blunt about this, because it is the failure we encounter most often. A backup that has never been restored is not a backup. It is a hopeful assumption with a monthly invoice attached.

Backup jobs fail silently in extremely boring ways. An agent stops reporting after an operating system update. A new server gets deployed and never gets added to the job. Storage fills up and the job starts skipping the largest — and usually most important — data set. A credential rotates and the job has been erroring for eleven weeks into an inbox nobody reads.

The fix is a restore test on a schedule. It does not need to be elaborate:

1. Monthly, small: restore a handful of individual files and one mailbox. Confirm the contents actually open and the data is current. Ten minutes.
2. Quarterly, medium: restore a full application or server into an isolated environment. Log into it. Run a report. Confirm it works, not just that it mounted.
3. Annually, full: a tabletop or live exercise of the whole plan. Assume the primary site is gone. Walk the entire sequence with the people who would actually be doing it.

Document what each test proved and how long it took. Those real timings become your true RTO — which is very frequently three to ten times longer than what anyone guessed on a whiteboard.

Every restore test we run for a new client surfaces at least one surprise. That is not a criticism of anyone. It is just what happens to systems that change every week and get verified once a year.

What the Plan Document Needs to Contain

The recovery plan is not a technical manual. It is written for a stressed person, possibly not the usual person, working under pressure. Keep it short and specific.

• Who decides. Name the person who declares an incident and authorizes recovery spending. Name a backup for that person.
• Who to call. Your I.T. provider, cyber insurance carrier, key vendors, legal counsel. With phone numbers, not just email addresses.
• Restore order. Which systems come back first, and their dependencies. Identity and DNS almost always come before applications — restoring an app whose authentication is still down accomplishes nothing.
• Where the keys are. Encryption keys, recovery codes, admin credentials — and how to reach them when the password manager itself may be inaccessible.
• How you communicate. If company email is down, what channel replaces it? Decide now, not during the outage.
• Manual workarounds. How does the team take orders, quote jobs, and answer customers on paper for 24 hours? This is the part that keeps revenue moving while engineers work.

Critically: keep a copy of this document somewhere that does not depend on the systems it describes. A recovery plan stored only on the file server you are trying to recover is not doing anyone any good. Print it. Keep a copy offsite.

Ransomware Changes the Sequence

A hardware failure and a ransomware event both end with “restore from backup,” but the path between is very different. With ransomware you cannot simply restore and resume, because you do not yet know how the attacker got in, how long they were inside, or whether your backups contain their tooling.

The sequence looks more like: contain and isolate, engage your insurer and any required legal or regulatory contacts, determine the intrusion window, restore to a point known to be clean, rebuild identity and rotate every credential, and only then bring systems back — hardened, and monitored closely.

Two implications for your backup design. First, retention depth matters: if your oldest backup is fourteen days and the intruder was in your network for thirty, every copy you hold may be compromised. Second, immutability matters, because modern attacks target backup infrastructure before they trigger encryption. Prevention is still cheaper than recovery — our guide to stopping phishing before it costs you money covers the front door that most of these incidents come through.

Budgeting Without Overbuying

You do not need enterprise-grade continuity for every system in the building. You need it for the handful of systems the business genuinely cannot run without. Spread your spending according to those RPO and RTO tiers rather than buying a single expensive solution and applying it uniformly.

A sensible progression for most small and mid-sized companies:

1. Cover the gaps first. Cloud application backup for email, files, and CRM. Low cost, closes the most common blind spot.
2. Make one copy untouchable. Immutable or offline retention for your most critical data set.
3. Add monitoring you will actually see. Backup failure alerts that reach a human who is accountable for them.
4. Buy speed only where speed pays. Rapid-failover continuity appliances or warm standby environments for the one or two systems with an RTO measured in hours.
5. Test, then adjust. Let real restore timings tell you where the remaining money should go.

Also confirm what your cyber insurance policy actually requires. Many carriers now expect multi-factor authentication, offline or immutable backups, and documented testing as conditions of coverage. Discovering a coverage gap during a claim is an expensive way to learn the terms.

A 30-Day Starting Plan

If your current answer to “how are we backed up?” is a shrug, here is a month of work that will move you further than any product purchase.

• Week 1 — Inventory. List every system holding data the business depends on, including cloud apps and anything a department bought without telling I.T. Mark what is currently backed up and what is not.
• Week 2 — Set targets. Assign an RPO and RTO to each system with input from the people who use it. Identify the gaps between target and reality.
• Week 3 — Close the biggest gap. Usually cloud application backup or immutable retention. Pick one, implement it, verify the first successful job.
• Week 4 — Test and write it down. Run a real restore. Time it. Draft the one-page recovery plan and store a copy offsite.

That is a genuinely achievable month, and it converts an unknown risk into a known, managed one. From there it becomes maintenance rather than a project.

Bringing It Together

Data backup and disaster recovery is not a product you buy once. It is a set of decisions — what matters, how fast it has to come back, who does what — supported by tools and verified on a schedule. The businesses that recover well are rarely the ones with the most expensive stack. They are the ones who decided in advance, wrote it down, and practiced.

If you are not sure where your gaps are, we are happy to look. Frozen Crow helps small and mid-sized businesses design backup and continuity plans that fit their actual operations and budget, alongside our broader I.T. services and communications work. Reach out through frozencrow.com for a free, no-obligation consultation — we will walk your systems, tell you plainly what we would fix first, and leave you with a clear plan whether or not you work with us. Our team, your goals.