Business Backup and Disaster Recovery: What Owners Need to Know

Most conversations about business backup and disaster recovery stall on the wrong question — which product to buy — when the question that decides the outcome is how the copies are arranged and whether anyone has ever restored one. Verizon's 2026 Data Breach Investigations Report found ransomware present in 48% of all breaches analysed, and 88% of small and mid-size business breach incidents involved extortion malware, against 39% at large organizations. The same report notes that 69% of victims did not pay. What separates those two groups is almost never the backup software. It is the architecture around it.

RANGO Technologies designs and runs these systems for small and mid-size businesses across Miami-Dade and Broward from Miami Lakes. This article explains the design decisions in plain language: what RPO and RTO actually mean for your business, what the 3-2-1-1-0 rule buys you number by number, why immutability matters more than encryption, and the specific failure mode where ransomware encrypts the backup target because someone mapped it as a drive letter. For the hurricane-season operational timeline — pre-season, 72 hours, 24 hours, during, after — see the hurricane season IT disaster recovery checklist.

Table of Contents

• Backup and Disaster Recovery Are Not the Same Thing
• RPO and RTO in Plain Language
• The 3-2-1-1-0 Rule, Number by Number
• Immutability and the Mapped Drive That Got Encrypted
• An Unrestored Backup Is a Hypothesis
• What to Ask Before You Buy
• Deciding What Your Business Actually Needs

Backup and Disaster Recovery Are Not the Same Thing

A backup is a copy; recovery is a capability

A backup is data sitting somewhere. Disaster recovery is the tested ability to have that data running as a working system again, on hardware you can reach, within a period of time the business can absorb. Vendors sell the first and imply the second. The gap between them is where most bad weeks happen.

The practical test is simple. If your main server were gone right now — not corrupted, physically gone — how many hours until staff are working again, and who performs each step? If nobody can answer without opening a vendor portal to look, you have backup and not recovery.

Where owners are usually surprised

Three surprises come up repeatedly. First, the restore takes far longer than the backup did, because downloading several terabytes over a business internet circuit is bounded by bandwidth, not by software. Second, the backup covered the file server but not the cloud mailboxes, the accounting SaaS, or the line-of-business database that quietly writes to a workstation under someone's desk. Third, the person who knew the procedure left the company.

None of these are exotic. All of them are found by a restore test and by nothing else.

RPO and RTO in Plain Language

RPO: how much work you are willing to redo

Recovery point objective is the age of the data you fall back to. If backups run nightly at 10 PM and the server fails at 4 PM, you lose the day's work — an 18-hour RPO in practice. Somebody re-enters those orders, invoices and clinical notes by hand, from memory and paper, while also dealing with the outage.

Owners usually pick an RPO by asking a concrete question: how many hours of re-keying can this team absorb without missing payroll, a filing deadline or a patient appointment? For most small businesses the answer for the one or two critical systems is measured in single-digit hours, and for everything else a nightly copy is genuinely fine.

RTO: how long you can be down

Recovery time objective is how long the business can operate without the system before the damage stops being an inconvenience. It is a business decision, not a technical one, and it varies wildly by system. A medical practice's imaging archive and its marketing file share do not deserve the same number.

Set them per system, not per company

A single company-wide RTO is either unaffordable or useless. Rank systems the way Ready.gov's business continuity guidance describes in a business impact analysis, then assign targets to the top few. Spending on a four-hour RTO for the two systems that carry revenue is nearly always a better use of money than spreading the same budget thinly across everything.

The 3-2-1-1-0 Rule, Number by Number

Three copies on two kinds of media, one of them offsite

The classic 3-2-1 rule: three copies of the data, on two different media types, with one copy offsite. Three copies because the production data and a single backup can be lost by the same event. Two media types because a shared failure mode — a controller, a firmware bug, a filesystem defect — can take out identical devices together. One offsite because fire, flood, theft and storm surge are location-scoped events.

In South Florida "offsite" deserves scrutiny. A second copy in a building four miles away shares a wind field, a flood plain and often a utility feed. Meaningful separation means a different region, which is exactly why RANGO describes its service as it does: Geographically separated, hurricane-resilient backups with regular restore testing. The build details are on the cloud backup and disaster recovery page.

The added 1: one copy offline or immutable

The fourth number is the modern addition, and it exists because of ransomware specifically. CISA's #StopRansomware Guide puts it directly: maintain offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario. Offline means an attacker holding domain administrator credentials cannot reach it. Immutable means that even if they reach it, they cannot alter or delete it before the retention window expires.

The 0: zero errors on the restore test

The final number is the one everyone drops. Zero errors means the last restore test completed with no failures, and somebody wrote down the date, the system, the elapsed time and the result. Without that record, the other four numbers are a purchase order rather than a recovery capability.

Immutability and the Mapped Drive That Got Encrypted

What immutable actually means

An immutable backup cannot be modified or deleted for a defined retention period, by anyone, including an administrator and including the backup software itself. Object-lock storage and hardened repositories implement this at the storage layer rather than by permissions, which is the important distinction — permissions can be changed by whoever holds the right credentials, and that is precisely who is attacking you.

Encryption is not a substitute. Encryption protects confidentiality if someone steals a copy. It does nothing to stop that copy being deleted or re-encrypted by an attacker who already owns your administrator account.

The mapped drive that got encrypted

Here is the failure mode, and it is a common one. A business backs up to a NAS or an external array. For convenience, that target is mounted on the server as a drive letter, or reachable via an SMB share with the same credentials the server uses. Ransomware runs on that server with those credentials, walks every reachable path including the backup volume, and encrypts the backups along with the production data. The backup job reports success right up to the moment it does not, because from the operating system's point of view nothing unusual happened.

A backup target that your production server can write to freely is an extension of your production server. It survives hardware failure and accidental deletion. It does not survive an intruder with credentials, which is the threat it is most often bought to address.

Credential separation is the actual control

The DBIR data explains why this matters so much now: 73% of ransomware victims had an associated infostealer infection or credential-leak event in the year before the attack, and 50% had that credential event within 95 days. Attacks arrive on stolen logins, not on clever exploits, so the defence has to assume the login is compromised.

That means the backup system uses its own accounts, not domain accounts. Multifactor authentication on the backup console. No reuse of the server's credentials for the repository. Alerting when retention or deletion settings change, watched by someone — this is one of the higher-value detections in a managed detection and response service, and it belongs in the same conversation as the rest of your cybersecurity controls rather than being treated as a storage question.

An Unrestored Backup Is a Hypothesis

What a restore test proves that a dashboard does not

A completed job proves that bytes were written. A restore proves that the bytes are readable, that the database is transactionally consistent, that the application starts, that licensing survives the move, that the documentation is accurate, and that a human being on your team can perform the procedure under pressure. Only one of those is visible in a status report.

How often, and what to test

For the systems ranked critical, restore something quarterly. Full-system recovery to isolated hardware or a sandbox once a year. File-level restores can be spot-checked monthly in a few minutes, and are worth it because they catch scope problems — the folder nobody added, the new SaaS application nobody licensed a connector for.

Test the systems in the order your impact analysis ranked them, and rotate so that over a year every critical system has been recovered at least once.

Write down the numbers you measured

Record the elapsed time. If the recovery of your primary database took eleven hours and your stated RTO is four, you do not have a four-hour RTO — you have an aspiration and a measurement that disproves it. That is a useful, cheap discovery, and it is the input for deciding whether to spend on faster recovery. The NIST Cybersecurity Framework treats Recover as an ongoing function with its own improvement loop, which is the right mental model: the number gets better because you measured it, not because you bought something.

What to Ask Before You Buy

Questions that separate real answers from brochures

Ask any provider, including us, these five, and expect specifics rather than adjectives.

1. What are the RPO and RTO for each of my critical systems, stated as numbers, and what were they in the last actual restore test?
2. Where physically are the copies, how far apart, and is one of them immutable or offline?
3. Which credentials can delete or alter a backup, and what happens if my domain administrator account is compromised?
4. What exactly is in scope — servers, workstations, Microsoft 365 mailboxes and files, and each SaaS application by name?
5. When was the last full-system restore performed, and can I see the written result?

If the answers to two and five are vague, the rest does not matter much.

What good looks like operationally

Backups monitored daily by a person who is accountable for failures, not only by an alert nobody reads. Retention long enough that a slow-burning problem — corruption discovered three weeks later, a mailbox deleted last quarter — is still recoverable. A written recovery runbook stored somewhere that does not depend on the systems being recovered. And restore testing on a schedule you can see, which is why RANGO's managed IT services treat it as recurring work rather than as a billable project you have to remember to ask for.

Deciding What Your Business Actually Needs

Not every business needs near-zero RPO and a four-hour RTO, and being sold one is a common way to overspend. Plenty of small companies are well served by nightly backups, an immutable offsite copy and a documented one-day recovery for most systems, with tighter targets on the one or two that carry the revenue. The point of the exercise is to choose those numbers deliberately instead of discovering them during an incident.

If you do not currently know your RPO and RTO, when the last successful restore test happened, or whether any copy of your data is beyond the reach of a compromised administrator account, those three answers are the whole agenda. RANGO's free IT assessment will produce them in writing, along with what it would cost to close whichever gap actually matters. Request a free IT assessment online, or call (305) 901-8990, Monday through Friday, 8:00 AM to 5:00 PM ET.