Backup and Disaster Recovery
Backup is the last step, not the first.
Anyone can copy your data. But, staying open through a failed server, ransomware attack, or a building you cannot get into takes a continuity plan, not a backup product. Which parts of your business cannot stop, how long each can be down before it costs you, and what keeps people working until it is back. We answer those with your leadership team, then size and test recovery to match, so the first time you need it is not the first time it runs.
✓ Verified restores, not green checkmarks
✓ Critical systems back in minutes, not days
✓ Recovery copies ransomware cannot reach
✓ A written plan your leadership owns
THE PROBLEM
"We have backups" is the most dangerous sentence in IT
It is dangerous because it is usually true, and rarely enough.
A backup runs overnight. A green light says it succeeded. Everyone moves on, confident the business is protected. Then a server fails, or ransomware locks every file, or a pipe bursts over the server closet, and the questions start. Which systems do we bring back first? How do we take orders, see patients, or ship product in the meantime? Who tells the customers? How old is the last good copy, and has anyone ever actually restored from it?
For most organizations, those answers arrive for the first time during the emergency, because nobody ever asked the question that comes before backup: what does this business need in order to keep running?
That is the quiet loss. Not a dramatic failure, but false confidence, accumulating month after month, that holds right up until the moment you need it to hold. The gap between “we have backups” and “we can keep operating” is where businesses quietly lose data, days, customers, and sometimes the whole organization.
THE REFRAME
Business Continuity is the goal. Backup is a tool.
Most providers sell backup first and call it protection. The order is backwards. Backup is the technical answer to a business question, and if nobody asked the question, the answer is a guess dressed up as a product.
For a fuller explanation of how these pieces fit together, read
Keeping a business running is built in three steps, in this order:
Know what must not stop
Which parts of the business, if they went dark, would hurt within hours, and how much loss could each one absorb?
Decide how you stay open
When something happens, who decides, how do people keep working, and what comes back first?
Build and test the recovery
Can your systems actually be brought back inside the tolerances you set, and has anyone proven it?
Know what must not stop
Every business has a handful of things that, if they stopped, would stop the business. A practice cannot see patients without scheduling and records. A manufacturer cannot ship if the ERP and the shop floor stop talking to each other. A contractor cannot invoice. A lender cannot fund.
A business impact analysis is the disciplined version of a question most leaders have never been asked directly: which functions matter most, and how long could you go without each one? It is not a technology exercise. It is a leadership conversation, and it produces two numbers for every critical function.
How much work can you afford to lose? If a system failed right now, how far back is acceptable? An hour? A day? A week? This sets how often that system must be backed up. (The industry term is Recovery Point Objective, or RPO.)
How long can you afford to be down? From the moment something breaks, how long until people must be working again? Minutes? Hours? Days? This sets how fast that system must be recoverable, which is a different problem from whether the data exists. (The industry term is Recovery Time Objective, or RTO.)
Most leaders cannot answer these with confidence. That is not a failure of leadership. It is a failure of every provider who sold backup and never had the conversation. Once you can answer them, recovery stops being a guess and becomes a decision, sized to your business and your budget.
Start it yourself. Before we ever talk, you can begin your own business impact analysis with six questions:
- Which systems or processes, if they stopped today, would stop revenue, production, or patient care within a day?
- For each one, how long could you operate without it before the damage became serious?
- How much work could you lose and realistically recreate?
- What does each one depend on that you do not control: internet, phones, email and identity, a vendor’s cloud, a single key person?
- Who decides what happens next, and who needs to hear from you within the first hour: staff, customers, patients, regulators, your insurer?
- What do your contracts, your regulators, or your cyber insurance policy already require you to have in place?
If any answer is “I would have to ask,” that is the gap.
Decide how you stay open
A business impact analysis tells you what matters. A business continuity plan is the written answer to what you do about it when something happens, and it is the piece almost every organization is missing.
Disaster recovery is about restoring systems. Business continuity is about keeping the business operating while that happens, and sometimes when it cannot happen right away. In plain terms, the plan covers:
- Who is in charge. Who declares an incident, who makes decisions, and who does their job if they are the one on vacation when the Sunday alert fires.
- How people keep working. Where staff work if the building is unavailable, what they do by hand if a critical system is down, and which processes can wait.
- What comes back first. The recovery order, decided in advance by business priority, not by whichever server the technician reaches first.
- How you communicate. How you reach staff, customers, and vendors when email and phones may be part of the problem.
- Who you call. Vendors, insurers, counsel, and your IT partner, with the numbers written down somewhere the outage cannot take with it.
- How the plan stays alive. When it is reviewed, when it is walked through as a scenario, and what triggers an update.
Your leadership owns the decisions in this plan. Our job is to make sure the questions get asked, the answers get written down in a document you own, and the plan gets revisited before it goes stale, as part of the strategic reviews already built into our partnership.
Build and test the recovery
Only now does backup enter the picture, and now it is sized to something real. Here is the distinction most providers blur, because blurring it is profitable.
A backup is a copy. Recovery is staying in business.
Backup | Disaster Recovery | |
|---|---|---|
What it is | A copy of your data, stored somewhere | The tested ability to keep operating when something goes wrong |
The question it answers | “Do we still have the files?” | “How fast are we working again, and how much did we lose?” |
When it saves you | You deleted a file or need an older version | A server dies, ransomware hits, or you lose the building |
What it protects | Your data | Your operations, your revenue, your reputation |
How most providers treat it | Sell it and call it protection | Rarely build it, almost never test it |
Backup is necessary. It is not sufficient. A copy of your data does nothing for you if it takes three days to turn it back into a working business, or if the last clean copy is a week old, or if no one ever verified it would restore.
What real recovery looks like in practice
Restore the whole system, not just the files. Backups capture complete system images, so a failed server can be rebuilt exactly as it was, settings and applications included, instead of being reinstalled and reconfigured from scratch while your team waits.
Lose minutes, not days. Backups run as frequently as the tolerance you set in step one requires, in some environments as often as every hour. The tighter your tolerance, the less work disappears when something fails.
Keep working while we fix the original. If a critical server goes down, we can run a working copy of it directly from the backup system within minutes, so your team keeps operating while the original is repaired or replaced. This is the single biggest difference between backup and recovery, and it is the part most providers cannot deliver.
Survive the loss of the building. Backups are replicated to a secure off-site location. If fire, flood, or theft takes the whole site, your systems can be brought up remotely so the organization keeps functioning from wherever your plan says people work.
Know it works before you need it. Every backup is automatically tested to confirm it will actually boot and restore, not just that the job reported success. An untested backup is a hope, not a plan. We replace the hope with evidence.
Backups ransomware cannot reach. The most common disaster today is a security event, so recovery copies are isolated so an attack that encrypts your live systems cannot encrypt them, and scanned so you do not restore the infection along with your data. Recovery design is reviewed alongside the security program led by our full-time in-house CISO, Matthew McCanne.
WHO OWNS THIS
This is the work of a chief information officer
In a large enterprise, the CIO owns continuity. They ask the leadership team what must not stop, translate the answers into tolerances, build the plan, and make sure the recovery investment matches it. A 75-person company cannot hire that person against coastal salaries, so the work usually falls to nobody. The provider sells backup. The owner assumes it is handled. The question never gets asked.
Our Fractional CIO practice is led by the company’s founder, not an account manager working a quota, and it is included in the managed partnership rather than sold as a separate engagement. Business impact analysis and continuity planning are part of that relationship, built with your leadership and maintained through the same strategic reviews that carry your roadmap and budget.
Ask your current provider a simple question: who owns our continuity plan? If the answer is “we do your backups,” nobody does.
SELF-PLACEMENT
Where does your organization sit today?
Unknown.
Backed up, untested.
Recoverable data.
True continuity.
The goal is not to sell you true continuity regardless of cost. It is to show you honestly where you are, and right-size the climb to what your business actually needs.
How We Deliver It
Outcome
Interruptions absorbed, workarounds normalized, risks aging silently toward the day they stop being cheap to fix. None of it shows up as a line item. All of it shows up in what your people did not get done.
Process
Deliverables
- A documented business impact analysis: critical functions, tolerances, and dependencies, in language your leadership team wrote with us
- A written business continuity plan you own, with recovery priorities, decision roles, and communication steps
- Backup state assessment and an honest gap report
- A recovery recommendation with clear, comparable pricing, sized to your tolerances
- Daily monitoring with failure investigation and remediation
- Documented restore test results, so “it works” is a fact, not a promise
- Client-owned recovery documentation you keep whether or not you stay with us
- Plan review on a schedule and after any material change, inside your strategic business reviews
Impact
Leadership stops carrying an invisible risk it cannot quantify. Continuity becomes a line in the strategic roadmap and the budget, decided on purpose, instead of a panic during an outage. The business can take risks, grow, and move forward knowing the floor will hold.
DIFFERENTIATOR
Verified, not assumed
This is the standard that runs through everything we protect. Most providers trust the dashboard. We trust the test.
- Inventory is reconciled against what is actually on your network, not inherited from a list.
- Backups are restore-tested, not assumed to work because the job said “success.”
- Failover is tested, not assumed to work because it is configured.
- Recovery priorities are decided in advance by your leadership, not improvised by whoever answers the alert.
- Native cloud retention in Microsoft 365 and Google Workspace is treated as what it is, a short-term convenience, not a backup.
If a competing proposal delivers the same verified recovery for less, it deserves your serious consideration, and we would tell you so.
IF YOU ARE HELD TO A STANDARD
In regulated industries, continuity is a requirement, not an extra
If you operate under HIPAA, a contingency plan is a required part of the Security Rule: a data backup plan, a disaster recovery plan, and an emergency mode operation plan, with testing procedures and an analysis of which applications and data are critical expected alongside them. That last item is a business impact analysis by another name. Defense contractors working toward CMMC are assessed on how backups are protected. Cyber insurance applications increasingly ask whether backups are isolated from your network and whether recovery has been tested, and the answers affect coverage and premiums.
The three steps above produce the evidence these frameworks ask for as a byproduct of doing the work properly, rather than as a scramble before an audit or a renewal.
PROOF
See the proof, not just the promise
Your questions answered
Frequently asked questions about backup and disaster recovery
What is the difference between backup and disaster recovery?
What is the difference between disaster recovery and business continuity?
What is a business impact analysis, and do we really need one?
Is business continuity planning included, or is it a separate consulting engagement?
Who should own our business continuity plan?
How often should our backups run?
As often as your tolerance for lost work requires. If losing a full day of work would be damaging, a once-a-day backup is not enough. Modern recovery systems can back up critical systems as frequently as every hour, so the real question is not what is technically possible but how much work your organization can afford to lose. We set the frequency to that answer.
How do I know our backups actually work?
What are RTO and RPO?
Is our Microsoft 365 or Google Workspace data backed up automatically?
These platforms have built-in retention and recovery features, but you should verify which data is protected, for how long, and whether your recovery needs require a separately configured backup.
How fast can we recover after a server failure or ransomware attack?
Can ransomware encrypt our backups too?
Does HIPAA require a business continuity plan?
What does disaster recovery cost?
Stop guessing when it comes to business continuity
Six questions your leadership team can answer this week.
