Backups & disaster recovery
If ransomware hit Monday morning, how much would you lose?
A week of revenue. Patient charts you can’t open. Payroll you can’t run. Two clients quietly interviewing your competitor by Wednesday. The ransom is not the cost of the attack. The cost is everything that breaks while it’s ongoing.
The 3-2-1 rule, made specific
Three copies. Two media. One offsite and immutable.
The 3-2-1 rule is decades old and still right. The mistake most shops make is calling a single synced cloud copy “offsite” and going home. Synced copies inherit the ransom. Immutable copies do not.
3 copies of data
The production copy you work from every day. A local backup copy on a different machine. An offsite copy you can reach when the building is on fire.
Typical stack
Production system + local backup target + cloud backup target
2 different media types
Disk and object storage. Or disk and tape. The point is that one failure mode (a virus that targets disk, a fire in the server room) cannot take both at once.
Typical stack
Local NAS with snapshots + cloud object storage
1 copy offsite & immutable
Offsite alone is not enough. Ransomware reaches synced cloud copies routinely. The offsite copy has to be immutable - object-lock or write-once-read-many - so even an attacker with admin credentials cannot delete it.
Typical stack
Object-locked cloud storage (write-once, immutable)
RTO and RPO, in plain English
Two numbers decide everything else.
RPOrecovery point objective
How much data you are willing to lose, measured in time. Everything since the last clean backup is gone.
RTOrecovery time objective
How long you can be down before the business takes lasting damage, measured from the incident.
These are design targets, not guarantees: the numbers we design the backup stack against and check with scheduled restore drills.
| Tier | RPO | RTO |
|---|---|---|
Critical systems EHR, accounting, line-of-business apps | 1 hour | 4 hours |
Important systems File shares, email, SharePoint | 4 hours | 24 hours |
Routine systems Workstations, dev environments | 24 hours | 72 hours |
Default targets. Yours get tuned in the scoping call based on what actually hurts when it goes down.
The stack, layer by layer
Specific capabilities, not vague categories.
Most backup pages hide behind “enterprise-grade solutions.” Here are the four layers every stack we design has to have. The specific products get named in your SOW.
Backup software
Database-aware backup for servers and computers
We match the method to the machine. Servers and the machines running your virtual systems get a backup that pauses the database first, so the copy is clean. Laptops and desktops get a lightweight version. The specific platform for your setup is named in your statement of work.
Immutable storage
Object-locked offsite tier + local snapshots
The offsite copy goes to object storage with object-lock, so it cannot be altered or deleted even with admin credentials. A local snapshot tier gives the fastest first restore when you need a file back in minutes, not hours.
Restore verification
Scheduled restore drills + written attestation
On a set cadence we pull a sample restore, document the result, and file the attestation in the compliance binder. A backup nobody has restored is a hope, not a backup.
DR runbook
Documented per-customer, exercised regularly
One-page runbook per environment: what to do first, second, third when everything is down. Names, phone numbers, vendor accounts, decision tree. Walked through in a tabletop exercise so it works under pressure.
When ransomware actually hits
Six steps, in order, while the clock is running.
This is the runbook we follow when an attack is confirmed. The order matters. Skipping step two costs more than anything else on this list.
- 01
Isolate affected systems
Pull the network. Disable the SSO tokens. Disconnect the VPN. Stop the spread first - everything else can wait fifteen minutes.
- 02
Validate clean backups exist
Before anything else, confirm the immutable copy is intact and the last clean backup is on a snapshot the attacker could not touch. If backups are compromised, the response changes entirely.
- 03
Identify dwell time and entry point
How long has the attacker been inside? Where did they get in? This determines which backup point is actually clean. Restoring from a backup that already contains the malware is the most common preventable mistake.
- 04
Coordinate with insurance and authorities
Notify your cyber insurance carrier within the contractual window (usually 24-72 hours) or you forfeit coverage. Loop in the FBI IC3 portal for tracking, and your attorney for breach-notification obligations under Utah Code 13-44 if PII was involved.
- 05
Restore from clean snapshot
Spin up the restored environment in an isolated network segment, validate it is clean, then cut production over. Critical systems first per the RTO tier. Routine workstations get the last slot.
- 06
Post-incident report and remediation
Written report inside two weeks: what happened, what got restored, what changed in the environment afterward (MFA rollout, segmentation, EDR, whatever the gap was). The lessons get added to the runbook and the next scheduled drill.
Why generic cloud backup falls short
“We back up to the cloud” is the most common false comfort in small-business IT.
If your backup story is “everything syncs to OneDrive,” you have a sync product, not a backup product. The four gaps below are what separate the two.
Ransomware-aware snapshots
Generic cloud sync (OneDrive, Google Drive, Dropbox) propagates the encrypted versions of your files in real time. Without versioned, ransomware-aware snapshots, your cloud copy is the encrypted copy.Immutable storage for compliance
HIPAA, PCI, and SOC 2 increasingly expect write-once-read-many storage for backup retention. Consumer cloud backup is mutable by design - the auditor will not accept it.Database-aware vs file-level
Backing up a SQL database file while SQL is running gives you a corrupt restore. A database-aware backup pauses the database first, then captures. Same goes for Exchange, Active Directory, and the machines running your virtual systems.Recovery testing cadence
A backup you have never restored is not a backup, it is a hope. Quarterly sample restores, annually a full DR drill. Most generic backup products do not even surface restore-test results in their console.
FAQ
The questions worth asking
Whether cloud-only counts, how often we test restores, and what we do when someone demands a ransom.
Find out what your current backups would actually do under attack.
A backup assessment is a paid two-week engagement: we map your current stack, run a real restore test, and tell you the actual RPO and RTO you would hit. Then you decide what to change.
Prefer the phone? (435) 227-5583