Does Your Business Have a Real Data Recovery Plan — or Just Backups?

Most small businesses in the Monterey Bay Area have backups running somewhere. A daily sync to the cloud, maybe an external drive, possibly a backup tool bundled with their server software. That’s a start — but it’s not a plan.

A backup is a copy of your data. A data recovery plan is the documented, tested process that tells you exactly how to get operations running again after a failure. Who is responsible for what. Which systems come back online first. How long you can afford to be down. Whether the data you’re restoring is actually clean. Most businesses have the first thing and not the second — which means they’ve paid for insurance but haven’t filled out the claim form in advance.

For businesses across Salinas, Monterey, and the broader Central Coast, that gap matters more than ever heading into summer. Wildfire season, ransomware, and aging infrastructure don’t wait for a convenient moment to test whether your backups actually work.

The Two Numbers That Define Whether Your Recovery Plan Actually Works

Before you can evaluate your recovery setup, you need two numbers: RTO and RPO.

RTO (Recovery Time Objective) is how long your business can afford to be down before the damage becomes serious — lost revenue, broken client commitments, compliance violations.

RPO (Recovery Point Objective) is how much data you can afford to lose — measured in time. If your RPO is four hours, that means you can live with losing up to four hours of transactions or records.

These numbers look different depending on who you are. A Salinas accounting firm in the middle of tax season might need an RTO of four hours and an RPO of one hour. A small nonprofit running monthly reports might tolerate a 24-hour RTO and an end-of-day RPO. Neither answer is wrong — but your backup configuration has to actually match your numbers.

Here’s where most setups fall short: a daily backup to a single cloud destination gives you an RPO of up to 24 hours and an RTO that depends entirely on your internet connection speed and how much data you’re pulling back. If your actual business requirement is tighter than that, the backup you have doesn’t meet the plan you need.

Setting these numbers isn’t a technical exercise — it’s a business decision. It forces you to ask: what does it actually cost when systems go down? That answer should drive every decision about your recovery architecture.

Why Ransomware Changed the Rules for Backup Design

Ransomware has a well-documented playbook at this point. Attackers get into a network, stay quiet for days or weeks mapping the environment, and then encrypt everything — including the backup systems — before triggering the ransom demand. They target backups specifically because organizations with clean, accessible backups don’t need to pay.

Small and mid-sized businesses are now the most common ransomware targets, and the Monterey Bay Area is not insulated from that reality. A law firm in Monterey, an agricultural operation in Salinas, a financial services office in Watsonville — all of these are attractive targets precisely because they hold sensitive data and often lack enterprise-grade defenses.

A backup system that’s ransomware-resistant needs at least two things that most basic setups don’t have:

• An immutable backup copy — data that cannot be encrypted, deleted, or modified by compromised credentials, no matter what access an attacker gains
• An offline or air-gapped copy — at least one backup that is physically or logically disconnected from the production environment

The 3-2-1 rule — three copies of data, on two different media types, with one copy offsite — has been the standard framework for years and remains a reasonable starting point. But Microsoft’s own guidance on ransomware resilience frames it clearly: 3-2-1 plus immutability is the current minimum for any business that cannot afford to pay a ransom or lose its data.

If you’re reviewing your current backup vendor, the question to ask is not “how often do backups run?” The question is: “Do we have an immutable copy, and when did we last verify it exists and is intact?”

PSPS Season Is a Disaster Recovery Scenario Too

Ransomware gets most of the attention in cybersecurity discussions, but Monterey County and the Salinas Valley have a second category of disaster that deserves equal weight in any recovery plan: Public Safety Power Shutoffs.

PG&E’s PSPS program has cut power to tens of thousands of homes and businesses across Northern and Central California in recent years, and California’s 2026 wildfire outlook from June through August is rated above average. A power outage that runs 18 hours to several days — a realistic PSPS window — creates specific IT risks that go beyond lost productivity:

• In-progress transactions get corrupted when servers lose power without a clean shutdown sequence
• On-premise servers can be destabilized by abrupt power loss, particularly older hardware without battery backup
• Cascading failures can follow when systems come back online out of sequence after an extended outage

A recovery plan that only accounts for ransomware or hardware failure leaves your business exposed to a scenario that is, frankly, more likely for most Central Coast organizations. The recovery plan needs a PSPS-specific section: what’s protected by UPS battery backup, what shuts down cleanly on generator power, which cloud-hosted systems can keep employees working during an extended local outage, and who makes the call to initiate a controlled shutdown if a PSPS warning goes out.

This is also where proactive network monitoring adds real value — systems that are being watched continuously can flag instability before a power event turns into a data loss event.

Backups vs. a Real Data Recovery Plan: What’s the Difference?

This breakdown shows the key differences between simply running backups and having a documented, tested data recovery plan — and what each one actually covers.

RTO and RPO Requirements by Business Type

These are general ranges based on common business scenarios in the Monterey Bay Area. Your actual numbers depend on your operations, revenue impact per hour of downtime, and any compliance obligations you carry.

The Most Common Failure Point: The Restore You’ve Never Run

Here’s a scenario that plays out more often than it should: a business discovers their data is gone or encrypted, calls their IT provider, and learns for the first time that the last successful restore test was never documented — or never happened at all.

A backup you have never actually restored from is a theory. You don’t know your real RTO until you’ve timed a full restore. You don’t know whether your backup data is clean until you’ve pulled it back and verified it. And you definitely don’t know whether the person who needs to run the restore in an emergency knows how to do it.

A real data recovery plan specifies:

• Who runs restore tests — a named person or team, not “IT” in general
• How often tests happen — quarterly at minimum for critical systems
• What gets documented — actual recovery time recorded, not estimated
• How data integrity is verified — confirming restored data is clean before it goes back into production

One of the most common questions we hear from businesses evaluating their current IT setup — including organizations that have been operating for years without a formal IT partner — is some version of: “We have backups, but we’re not sure they actually work.” That uncertainty is the gap between having backups and having a recovery plan.

If you’re unsure how your current provider handles this, a good starting question is: “When did we last run a full restore test, and how long did it take?” If the answer is vague, that tells you something important. For more on what separates a proactive IT partner from a reactive one, this comparison of local versus national IT providers is worth reading.

Frequently Asked Questions About Data Recovery Plans