Operations · Storage & resilience
Backup Strategy Guide: Building a 3-2-1-1-0 Plan That Survives Ransomware
A backup strategy is more than running a backup job: it is a documented plan that guarantees you can recover within a known time, even after ransomware, hardware failure, or human error. The current standard is the 3-2-1-1-0 rule — three copies of your data, on two media types, with one offsite, one immutable or air-gapped, and zero errors proven by tested restores. The two modern additions exist because attackers now hunt and destroy reachable backups before encrypting production, so at least one copy must be beyond their reach, and you must regularly prove a restore actually works.
Key takeaways
- 3-2-1 is the floor, 3-2-1-1-0 is the standard. Add one immutable or air-gapped copy and zero unverified restores.
- RPO and RTO drive the design. RPO (how much data you can lose) sets backup frequency; RTO (how long you can be down) sets recovery architecture.
- Sync is not backup. Real-time replication copies ransomware too; use scheduled snapshots with separate credentials and immutability.
- RAID is not backup. RAID survives a dead disk; it does nothing against deletion, corruption, or encryption.
- An untested backup is a guess. Quarterly restore tests and one annual full recovery drill are what turn a backup into a recovery plan.
Most organisations that lose data were running backups when it happened. The backups simply had a gap that nobody noticed until recovery day — a copy the attacker could also reach, a job that had quietly failed for weeks, or a restore process no one had ever actually run. A real strategy closes those gaps before they cost you. This guide lays out a backup plan built for 2026 threats, aimed at teams running servers they own or rent rather than relying on a SaaS vendor’s defaults.
What makes a backup strategy, not just a backup?
A strategy is a backup plus three things a lone backup job lacks: isolation, verification, and a defined recovery target. A backup job copies data; a strategy answers the questions that matter during an incident — where the copies live, which one an attacker cannot touch, how recent the data is, how long recovery takes, and whether anyone has actually tested it. The difference is the difference between “we have backups” and “we recovered in four hours with no data loss.”
The discipline starts with knowing what you are protecting. Inventory your critical workloads — the systems the business cannot run without — including the shadow data that lives on a single laptop or in one finance spreadsheet. You cannot protect what you have not catalogued, and the most painful recovery failures usually involve data nobody remembered was load-bearing.
The 3-2-1 rule — and why 2026 needs 3-2-1-1-0
The 3-2-1 rule is the foundation: keep three copies of your data, on two different media or storage technologies, with one copy offsite. Three copies remove single points of failure, two media types ensure one technology fault cannot wipe everything, and the offsite copy survives a fire, flood, or theft at your primary site. It is intentionally simple, and it is still the right starting point.
What changed is the threat. Ransomware now treats your backups as the primary target — attackers move quietly through an environment for weeks, locate the backup systems, and destroy or encrypt every reachable copy before they trigger the main attack, specifically to remove your recovery options and force payment. The 3-2-1-1-0 extension answers that directly: the extra 1 is one copy that is immutable or air-gapped, and the 0 is zero errors — every backup verified by a real restore. Both were always good practice; ransomware made them mandatory.
What do RPO and RTO actually mean?
They are the two numbers that turn “back up the data” into an engineering target. RPO, your recovery point objective, is the maximum amount of data you can afford to lose, measured in time — if your RPO is one hour, you must capture a recoverable copy at least every hour. RTO, your recovery time objective, is the maximum time the business can be offline before the cost becomes unacceptable. RPO drives how often you back up; RTO drives how you architect recovery, because restoring 40 TB from cold object storage and spinning a service back up locally are very different timelines.
Set these per workload, not once for everything. A transactional database might need an hourly or continuous RPO and a one-hour RTO; an archive might tolerate a weekly RPO and a day-long RTO. Matching cadence and recovery design to actual business criticality is how you avoid both expensive over-protection and dangerous gaps. Write the numbers down before you choose tools — the targets dictate the architecture, not the other way around.
Why immutability and air-gap beat ransomware
An immutable backup cannot be modified or deleted during its retention window, even by an account with full administrator rights. It is typically implemented with WORM (write-once, read-many) policies or object lock on S3-compatible storage, so once a backup is written it is frozen until retention expires. That property is exactly what defeats an attacker who has stolen domain-admin credentials: they can encrypt production, but they cannot reach into the locked repository and destroy the clean copy.
Air-gapping takes isolation further by disconnecting a copy from the network entirely — tape in a vault, a rotated offline drive, or a logically air-gapped cloud target sealed behind a separate security domain, independent authentication, and API-only access with MFA. The two controls complement each other: immutability blocks tampering, air-gapping reduces reach. A critical caution that catches people out — real-time cloud sync is not a backup, because it mirrors changes instantly and will replicate ransomware encryption to your “backup” the moment it happens. A true backup uses scheduled snapshots with independent retention and separate credentials. One more discipline: scan data before it lands in immutable storage, or you risk writing a poisoned, undeletable copy.
Is RAID a backup?
No — and confusing the two is one of the most expensive mistakes in infrastructure. RAID protects against disk failure: if one drive in a mirrored or parity array dies, the array keeps running while you replace it. That is valuable for uptime, but RAID does nothing about the threats backups exist to handle. A file deleted by mistake is deleted across the whole array instantly. Ransomware encrypts every disk in the set at once. A corrupted write corrupts on all mirrors. RAID is availability, not recovery — see RAID levels explained for which array does what.
Backups are also distinct from disaster recovery, though people use the words interchangeably. A backup is a recoverable copy of data; disaster recovery is the broader plan for restoring whole systems and operations after a major incident, of which backups are one essential component. You need both, and they answer different questions — our disaster recovery guide covers the wider plan that your backups feed into.
How often should you back up?
As often as your RPO demands — the 3-2-1 rule sets how many copies exist, not how frequently they are made. For most business-critical workloads, daily is the practical minimum; for high-value systems like financial data or a busy transactional database, hourly or continuous protection is more appropriate. Resist the urge to apply one cadence everywhere: hourly snapshots of a static archive waste storage, while a once-a-day copy of a fast-moving order system can mean losing a day of transactions.
Retention deserves the same thought. A 30-day history is a common default and is often too short, because malware can sit dormant in your environment for weeks before activating — by the time you notice, your recent backups may already contain the infection. Ninety days or more gives you clean restore points to fall back to. Tier your retention so routine, frequent restore points cover everyday mistakes while longer-held copies cover slow-burning compromises.
A practical 3-2-1-1-0 setup for a dedicated server
On a single-tenant dedicated server, a dependable and inexpensive pattern looks like this: fast local snapshots on a second disk or NAS for everyday restores, scheduled encrypted backups to S3-compatible object storage in a different region for the offsite copy, and object lock enabled on that bucket so the offsite copy is also immutable. Open-source tools such as restic or BorgBackup handle deduplicated, encrypted, scheduled backups well; the example below uses restic against an object-locked bucket and, crucially, finishes by proving the restore works.
One detail that quietly ruins otherwise-good backups: databases need application-consistent copies. Backing up the live files of a running database can capture them mid-write and produce a restore that will not start. Take a proper dump (for example with pg_dump or mysqldump), or use a filesystem or storage snapshot that quiesces the database first, and back up that consistent artefact rather than the raw open files. The same logic applies to any stateful service: capture a consistent point, not a smear of a moving target.
# Encrypted, scheduled backup to object-locked (immutable) storage $ export RESTIC_REPOSITORY=“s3:s3.ca-central.example.net/backups-prod” $ restic backup /srv/data /etc —tag nightly processed 48213 files, 22.401 GiB in 3:11 snapshot a1b2c3d4 saved # Enforce retention; older snapshots age out, locked ones cannot be deleted early $ restic forget —keep-daily 14 —keep-weekly 12 —keep-monthly 12 —prune # The step that actually matters: prove a restore (the “0”) $ restic restore latest —target /tmp/restore-test —include /etc/hosts restored 1 file to /tmp/restore-test $ restic check —read-data-subset=5% no errors were found # Bucket has Object Lock (WORM) on -> even stolen creds can’t wipe history.
That gives you three copies (production, local, offsite), two media types, one offsite, one immutable, and — once you schedule the restore check — zero unverified backups. Pair it with tight access control: restrict restore permissions more tightly than backup permissions, require MFA, and demand dual approval before anyone can delete backups or change a retention lock. Hardening the server those backups run on matters too; our server hardening checklist covers the surrounding controls.
Testing restores: the step everyone skips
A backup you have never restored is not a backup — it is a hope. Confirming that a job completed is only half the work; you also have to prove the data comes back, comes back complete, and comes back inside your RTO. The failure pattern is depressingly consistent: a sync that broke after a password change three months ago, an immutability policy with a gap, a restore process that turns out to take three times longer than anyone assumed.
Build a testing cadence and hold to it: a quarterly restore of at least one critical system from each backup tier, a full disaster-recovery simulation once a year, and an ad-hoc test after any major infrastructure or software change. Document the date, the systems tested, the actual time taken, and any problems found — that record is what converts an assumed RTO into a measured one. As a useful yardstick, public guidance suggests verifying you can restore at least a week of operations. The teams that recover cleanly are not the ones with the fanciest backup tool; they are the ones who practised.
Keeping backups in-country and compliant
Where your backup copies physically live is a compliance decision, not just a technical one. An offsite copy that lands in another country can pull regulated data under a foreign legal regime, which may conflict with obligations like Canadian data residency under PIPEDA. When you configure that immutable offsite bucket, choose a region and provider whose jurisdiction you actually want your data sitting in — the topic is worth understanding properly, and we cover it in data residency explained.
One more resourcing note, since it surprises people: backups are not free of compute cost. Deduplication, compression, and encryption are CPU-bound, and on a heavily loaded server a nightly backup window competes with production work. If your backup jobs are running long or pushing the box hard, the server’s processor is often the constraint — our CPU comparison guide helps size that correctly. A good backup strategy accounts for the cost of making the copies, not just the cost of storing them.