The 3-2-1-1-0 Backup Rule: Building Backups That Survive Ransomware

The classic 3-2-1 rule asks for three copies of data, on two types of media, with one copy offsite. Ransomware has pushed the guidance to 3-2-1-1-0: add one copy that is immutable or offline, and zero errors after verification. The extra digits reflect how attackers now target backup systems before they encrypt production data.

01Why the original rule is no longer enough

Modern ransomware operators spend days inside a network before triggering encryption. During that time they locate and delete backups, steal backup administrator credentials and disable agents. A backup reachable with the same credentials as production is effectively part of the blast radius. The additional immutable copy ensures that even a fully compromised domain cannot erase every recovery point.

02What immutability means in practice

Immutable storage prevents objects from being changed or deleted for a defined retention period, even by administrators. Options include object-lock enabled storage in the cloud, hardened Linux repositories and tape or removable media stored offline. Choose a retention window long enough to detect a slow-burning compromise, commonly 14 to 30 days or more.

03Do not forget SaaS data

Microsoft 365 and Google Workspace provide availability, not necessarily backup in the sense of point-in-time restore after deletion or compromise. Third-party backup for mail, files, Teams and calendars protects against accidental deletion, malicious insiders and ransomware that syncs encrypted files. Include identity configuration in your recovery plan as well.

04Define recovery objectives per system

Not every system deserves the same investment. For each, agree a recovery time objective, how quickly it must return, and a recovery point objective, how much data loss is tolerable. A phone system may need minutes; an archive may tolerate days. These numbers drive technology choices and let leadership see the cost of tighter targets.

05Test restores like you mean it

The zero in the rule stands for zero errors on restore. Schedule quarterly tests that restore real systems into an isolated environment, time the process and record the result. Include a test of restoring from the immutable copy using documented steps and a different administrator. Findings from the test feed improvements.

06Plan for Canadian data residency

Many Canadian organisations prefer or are required to keep backup data in Canada. Check the region of your backup target, and whether replication or support access crosses borders. Document the location in your data register so that you can answer customers and regulators precisely.

07Write the runbook before you need it

During an incident people are stressed and time is scarce. A runbook lists the recovery order, credentials location, contacts, decision points and verification steps. Keep a printed or offline copy available, and make sure at least two people can follow it. Run through it in your annual tabletop exercise.

08Backup mistakes we see most often

The most frequent mistake is trusting a green status light. Jobs may run successfully for months while backing up the wrong data or an empty share. Others include joining backup servers to the production domain, retaining only a few days of history, forgetting databases and application configuration, and never testing recovery of the directory service. Another is sizing storage so tightly that retention is quietly shortened. Review coverage against your system inventory and verify that each critical system has a documented restore path.

09A 60-day backup improvement plan

Start by listing every system and assigning recovery objectives. In the first 30 days, close coverage gaps, separate backup credentials and enable immutability on at least one copy. In the next 30 days, run a restore test of one critical server and one Microsoft 365 or Google Workspace mailbox, document the time and issues, and fix them. Then schedule recurring tests and report results to leadership. This modest plan removes the largest recovery risks quickly.

10Backup priorities by sector

A clinic prioritises its medical record system and imaging archives. A law firm prioritises document management and email. A construction firm prioritises project files and accounting. A media agency prioritises very large asset libraries and may use tiered storage. Each sector has a different cost of lost data and a different tolerance for downtime, which should guide retention, frequency and technology choices.

11Details that are easy to overlook

Check that backups cover databases consistently, not just file copies, and that encryption keys for backup data are stored separately and recoverable. Confirm that retention covers the period over which an undetected compromise might persist. Include endpoints that hold unique data, such as designers' laptops, if they are not syncing to cloud storage. Verify that your backup alerts reach a monitored mailbox, and that someone is accountable for responding to failures within a defined time.

12Questions for your leadership team

Which data could we not re-create, and where does it live today? How long could we operate without our main application? Who can authorise a restore and who performs it? Where is the runbook if our email is down? What would it cost us per day of downtime, and does our investment in backup reflect that? Linking recovery objectives to financial impact makes budget conversations far easier.

Where this fits in your IT plan

Guidance like this works best when it is part of a coordinated programme rather than a one-off fix. These IT Experts services address the topic directly:

How IT Experts can help

IT Experts is a sub-brand of SAZ.ca, led by Ali Sedighi, MBA, combining senior-partner strategy with hands-on IT delivery. If this topic matches a situation in your organisation, book a free 30-minute consultation: call (604) 632-4959 or email info@SAZ.ca. We will give you a plain-language view of your options and, if useful, a fixed-price scope. We are an IT services and consulting firm, not a reseller, and there is no lock-in.

Frequently asked questions