Ransomware-Ready Backups: The 3-2-1-1-0 Rule for Business Systems

Here is an invented scene, not a real customer. It is Friday, 4:40 p.m. The owner of a 15-person online shop asks her IT contractor to restore last night's backup onto a spare server, something nobody has done in two years. It is meant to be a formality: the backup dashboard has shown a green tick every morning since January.

The restore finishes in eleven minutes, and the orders table is empty. Since a disk filled up in March, the nightly job has been writing a truncated dump, and it kept reporting success because nobody checked its exit code. Every tick was true. The job ran. Nobody had ever asked whether the file could be opened.

A backup you have never restored is a guess, and ransomware turns the guess into a loss. An attacker holding your admin credentials looks for your backups before he encrypts anything, so the old advice, three copies on two kinds of media with one off-site, no longer covers it. Today's version of the rule has two extra numbers, and they matter more than the first three.

The rest of this piece covers why smaller businesses are in the frame, what 3-2-1-1-0 means in practice, how to set recovery targets per system, what to back up in a business application, and how to rehearse the day it all goes wrong.

Why smaller businesses are the target

Attackers do not choose victims by brand. They scan for exposed logins, unpatched edge devices and reused passwords, then see what they caught. Small companies tend to have the same weaknesses as large ones with far fewer people to spot the problem.

The numbers agree. Verizon's 2025 Data Breach Investigations Report found ransomware present in 44% of the breaches it analysed, up from 32% the year before. In small and medium-sized businesses the share was far higher: 88% of breaches involved ransomware, against 39% at large organisations. The same report found that 64% of victims did not pay, and that the median payment had fallen to about $115,000.

That last figure is the good news and the warning at once. Fewer victims pay because more of them can restore. Sophos's State of Ransomware 2026 report, a survey of 2,158 IT and security leaders whose organisations were hit, found that 66% of those whose data was encrypted recovered it from backups, 12 points more than a year earlier. But the typical recovery bill still reached $1.7 million.

Attackers know backups decide the outcome, so they go after them first. Sophos's earlier research on compromised backups found that attackers tried to compromise the backups of 94% of the organisations they hit, and succeeded in 57% of those attempts. Where they succeeded, victims were almost twice as likely to pay the ransom and faced a recovery bill about eight times higher. A backup an attacker can reach is not a backup. It is another target.

From 3-2-1 to 3-2-1-1-0

The classic rule is simple: keep 3 copies of your data, on 2 different types of storage, with 1 copy off-site. It still works against hardware failure, theft and fire. Against a determined intruder it has a hole, because all three copies are usually reachable with the same credentials.

The modern rule adds two requirements:

• 1 immutable or offline copy. One copy that nobody, including your own administrators and the attacker holding their passwords, can change or delete until its retention period ends.
• 0 errors. A backup counts only if a restore test of it has completed without errors. Until then it is only a hope.

You can meet the rule with modest means. The live database is copy one. A nightly dump on a separate disk or server is copy two. A third copy goes to object storage at another provider, written with credentials that can add files but not remove them, and with a retention lock switched on. That third copy covers the off-site and immutable requirements together.

Immutability, in plain terms

An immutable backup is write-once: once a file is stored, the storage service itself refuses to modify or delete it until a date you chose. Amazon S3 calls this Object Lock, and several S3-compatible stores offer the same feature under the same name. It has two modes, and the difference matters.

• Compliance mode. Nobody can delete or overwrite a locked version before the retention date, not even the account's root user, and the period cannot be shortened.
• Governance mode. Most users cannot delete the object, but a user holding a special permission can override the lock. It is safer than nothing and weaker than compliance mode, because an attacker with the right permission can use it too.

The details are in the S3 Object Lock documentation. Whichever provider you use, check three things before you trust it: versioning is on, the lock mode is compliance (or the override permission is held by a person who is not an everyday admin), and the retention period is longer than the time you would take to notice an attack. Intrusions can go unnoticed for weeks.

If object lock is not available, an offline copy does the same job: an external drive or tape that is physically disconnected between runs, or a pull-based backup server that fetches data itself, so the production system holds no credentials to it.

Set recovery targets per system

Two numbers drive every backup decision. RPO (recovery point objective) is how much recent data you can afford to lose, measured in time. RTO (recovery time objective) is how long you can afford to be down. They are business decisions first and technical settings second, and they differ by system.

Orders are the clearest case. An online store that takes a hundred orders an hour cannot lose a day of them, because customers have already been charged and nothing remains to match them against. A shared folder of old brochures can wait a week. Set the targets by asking what each hour of loss or downtime costs.

Tier	Examples	Target RPO	Target RTO	Method
Tier 1: money in motion	Orders, payments, stock ledger, accounting	5–15 minutes	1–4 hours	Continuous log shipping or frequent incremental dumps, plus a daily immutable full copy
Tier 2: daily operations	Customers, HR and payroll, supplier records, uploaded files	24 hours	8–24 hours	Nightly snapshot to off-site storage with a retention lock
Tier 3: working files	Documents, exports, reports, media library	24 hours	2–3 days	Versioned object storage with delete protection
Tier 4: archive	Old invoices, closed years, legal records	1 week	1 week	Monthly immutable copy, long retention, encrypted

These figures are illustrative starting points, not standards. Your own numbers should come from your own cost of downtime. What matters is that every system has a tier, and that the tier is written down.

What to back up in a business application

A database dump is the first thing everyone thinks of and rarely the only thing you need. If you have ever restored a system and found it would not start, one of the following was probably missing.

• The database. Take a consistent dump or snapshot, not a copy of live data files, and keep the schema migrations version with it.
• Uploaded files. Product images, invoices, attachments and documents usually live outside the database. A database restored without its files has broken links everywhere.
• Configuration. Environment files, scheduled job definitions, server and proxy configuration, payment and courier settings.
• Secrets and keys. Application keys, encryption keys and signing keys. Without the application key, encrypted columns in a perfect database backup stay unreadable. Store these separately from the data they protect.
• Licences and integrations. Licence files, webhook secrets, API credentials and domain or DNS records. Rebuilding these under pressure costs hours.
• The recipe itself. A short document that says which version of the software, which server image and which steps rebuild the system from nothing.

Encrypt every copy before it leaves your network, and keep the encryption keys somewhere the backup storage cannot reach. A stolen backup is a data breach, and in many jurisdictions a reportable one.

Keep the keys apart

The weak point is usually separation, not technology. Four rules cover most of the ground:

1. Use a separate account at the storage provider for the immutable copy, ideally under a different owner login with its own multi-factor authentication.
2. Give the production server write-only credentials: it can add backups and nothing else. It cannot list, read, change or delete.
3. Keep admin credentials for backup storage out of the password manager and the single-sign-on that attackers reach through a compromised laptop.
4. Alert on backup events: a failed job, a deletion attempt, a retention change, or a day with no new backup at all.

Retention: how far back should you go

Keeping only last night's backup is dangerous, because a quiet intrusion may be weeks old and last night's copy may already contain the damage. A practical schedule for most small and mid-sized businesses is daily copies for 30 days, weekly copies for three months, and monthly copies for a year or whatever your accountant and local law require. Storage is cheap compared with a recovery bill.

Retention also protects you from yourselves. Someone deletes a product catalogue in error, someone imports the wrong spreadsheet, a bug corrupts a month of prices. A history of restore points turns those from disasters into afternoons.

Restore drills belong on the calendar

The final "0" in 3-2-1-1-0 is the one most teams skip. A backup that has never been restored has an unknown chance of working. The files may be empty, the key may be missing, the restore may take 30 hours instead of three. You want to learn this on a calm Tuesday.

Start small and make it routine. Every week, automatically restore the newest database backup into a throwaway environment and run a few sanity queries. Every month, restore one file set and open some files. Every quarter, rebuild a complete system on a clean server and time it. Once a year, run a tabletop exercise as if the main server were gone and nobody could reach the old one.

Record each result: date, what you restored, how long it took, and what went wrong. If a drill takes longer than the RTO you promised, change the plan or change the promise. A scheduler that takes snapshots, applies retention, and restores to a clean target in one step makes drills much cheaper to run. The short tour below shows one self-hosted example, StoreConsole's Backups module, working through exactly this loop.

A one-page incident runbook

The order of the first decisions matters more than any single step. Two questions gate every restore: are the backups intact and out of the attacker's reach, and does the restore point predate the intrusion? The flowchart shows the whole path, and the list after it is the short version to print.

When ransomware hits, people make their worst decisions in the first hour. Write the runbook while you are calm, print it, and keep one copy off the network. A short version looks like this:

1. Isolate. Disconnect affected machines from the network and from backup storage. Do not power them off if you may need memory evidence.
2. Call the right people. Name them in advance: the person in charge, your IT contact, your insurer, legal counsel, and whoever speaks to customers.
3. Protect the backups. Rotate every backup credential from a clean device and confirm the immutable copy is intact.
4. Find the way in. Before restoring, identify how the attacker entered and close it, or you will be encrypted again within days.
5. Restore in tier order. Rebuild from clean images, restore Tier 1, verify it, then move down the list.
6. Change every secret. Passwords, API keys, tokens, and the application key where it is safe to do so.
7. Report and review. Notify regulators and affected customers where the law requires it, then write down what you will change.

Government guidance is worth reading before you need it. The US CISA's StopRansomware resources include a practical response checklist that applies well beyond the United States.

Run the same Friday again with the advice applied. Every Monday at 6:00 the system restores the newest dump into a throwaway database and compares the order count with production. In March the check fails, and an email arrives saying orders: 0, expected about 4,200. The owner reads it over coffee, the contractor fixes the script within the hour, and behind it sits a copy in a locked bucket, written by a key that can only add files. What would have been a Friday-afternoon discovery is a Monday-morning email.

Key takeaways

• Attackers go after backups first. A copy reachable with your normal admin credentials will be encrypted or deleted with everything else.
• Use 3-2-1-1-0: three copies, two media, one off-site, one immutable or offline, and zero errors in restore tests.
• Give every system an RPO and RTO based on what downtime costs, not on what is convenient to configure.
• Back up more than the database: files, configuration, secrets, licences and the written rebuild recipe, all encrypted.
• Separate accounts, write-only credentials and a retention longer than an intruder's dwell time keep the immutable copy safe.
• Put restore drills on the calendar and record the results. A backup is proven by a restore, not by a green tick.

Anichur Rahaman is a software architect and the creator of StoreConsole. He designs commerce and ERP systems for growing businesses, with a focus on event-driven architecture, data integrity and self-hosted operations.