Backups That Survive Ransomware: The 3-2-1-1-0 Strategy for Websites and Servers

The worst time to discover that your backups were mounted read-write on the compromised server is after ransomware has encrypted production and deleted every snapshot it could reach. A backup strategy has to survive the same incident that destroyed the original. That is the logic behind 3-2-1-1-0.

The classic 3-2-1 rule says to keep three copies of data, on two types of storage, with one copy offsite. The modern 3-2-1-1-0 extension adds one offline or immutable copy and aims for zero backup errors after verification. The exact media matter less than the failure separation.

What 3-2-1-1-0 means

Why snapshots are not enough

Snapshots are excellent for fast rollback after a bad update, filesystem mistake, or short-lived incident. But a snapshot stored in the same control plane as the compromised server may be reachable with the same administrator credentials. That makes it a recovery convenience, not your only disaster-recovery layer.

The same warning applies to “backup” directories sitting on the production filesystem. If the machine, account, or disk fails, the copy fails with it.

Offline vs immutable

An offline backup is disconnected from the production environment except during controlled backup or restore operations. An immutable backup stays online but is protected by storage controls that prevent modification or deletion for a defined retention period. Both approaches aim to break the attacker’s ability to destroy recovery points.

Immutability is especially practical for automated backups because the data can be written continuously while retention controls stop an attacker from rewriting history. The storage credentials and policy administration still need strong protection; “immutable” should not mean “any administrator can turn immutability off instantly.”

Back up more than website files

• Databases: orders, users, posts, configuration, application state.
• Files: uploads, code not stored in source control, generated assets, mail if locally hosted.
• Configuration: web server, DNS, firewall, cron, environment variables, panel settings, certificates where appropriate.
• Secrets inventory: not necessarily raw secrets in every backup, but enough documentation to rotate and rebuild credentials safely.
• Infrastructure definitions: IaC, container manifests, package lists, and deployment scripts speed a clean rebuild.

The restore drill is part of the backup

A green “backup completed” notification proves that a job wrote something. It does not prove that the database dump is consistent, the archive decrypts, the application boots, or the credentials needed for restore are available during an outage.

1. Pick a recovery point without warning the person performing the restore.
2. Restore into an isolated environment, not over production.
3. Validate files, database integrity, authentication, and critical application workflows.
4. Record recovery time and missing dependencies.
5. Fix the runbook, then repeat until recovery is routine rather than heroic.

Ransomware changes the trust model

Assume the attacker may obtain a privileged account, API token, SSH key, or control-panel session. The backup system should require a different trust path for destructive actions. Separate credentials, MFA, write-only backup jobs, retention locks, and an account boundary can all reduce blast radius.

CISA explicitly recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity. That guidance is less glamorous than a security appliance because recovery discipline does not demo well — but it is what turns a catastrophic compromise into a rebuild.

A website/server backup schedule that is easy to operate

• Database backups frequent enough to meet your real recovery-point objective.
• Daily file/configuration backups for ordinary sites, more often for rapidly changing assets.
• One local or provider snapshot for fast rollback.
• One separate offsite destination.
• One immutable/offline retention tier with a longer window.
• Monthly restore tests for important systems; more often after major architecture changes.

LogicWeb’s knowledge base includes backup and security operations across shared hosting, WordPress, VPS, and dedicated systems. Whatever platform you run, keep at least one recovery copy outside the same failure and credential domain as production.

FAQ

What is the 3-2-1-1-0 backup rule?

It is a resilience model: three copies of data, two media or failure domains, one offsite copy, one offline or immutable copy, and zero unverified backup errors.

Are server snapshots enough for ransomware recovery?

Not by themselves. If the attacker can access the same control plane, snapshots may be deleted or encrypted. Keep an independent offsite and offline/immutable layer.

How often should I test backups?

Important systems should be restored on a recurring schedule and after major architecture changes. The right frequency depends on business impact and recovery objectives, but testing should be routine rather than exceptional.

Sources and further reading

• CISA #StopRansomware Guide
• LogicWeb knowledge base