The 3-2-1 backup rule — three copies, on two different media, with one offsite — has been the standard advice for thirty years. It still works. What has changed is that adversaries now go after the backup before they trigger the ransomware payload, which means the bar has moved. The rule is now sometimes written as 3-2-1-1-0: one of those copies must be immutable, and the entire process must verify with zero errors.
What changed
Ten years ago, backups were lost mostly to hardware failure, accidental deletion, or fire. The protection model assumed an honest threat. Today, the dominant threat is a deliberate one: an adversary inside the network, with sufficient privilege, deliberately removing your ability to recover before initiating the destructive action.
That changes what backup means. A backup that is reachable from the production environment, with credentials that exist anywhere in the production environment, is not really a backup against ransomware. It is a backup against accidents.
The modern principles
- Immutability. At least one backup copy must be immutable for a defined retention window — meaning it physically cannot be deleted or modified, even by an administrator, until the retention period expires. Object Lock on cloud object storage, immutable snapshot configurations on backup appliances, and tape are all valid implementations.
- Air gap or logical isolation. The backup destination should not be reachable using credentials available in the production environment. A separate identity domain, separate management plane, and separate network path.
- Verification. Backups must be tested, not just taken. The number of organisations that discover during a real incident that their backups have been failing for months is depressingly high.
- Encryption at rest, with key custody understood. If the keys are accessible to anyone who can compromise production, the encryption is a compliance check rather than a protection.
Recovery objectives and what they actually mean
Two metrics drive backup and DR design: RPO (Recovery Point Objective — how much data can you afford to lose, measured in time) and RTO (Recovery Time Objective — how long can you afford to be down). Both are organisational decisions, not technical defaults. We see two common errors:
- Setting RPO and RTO without business consultation. The technology team picks numbers based on what the existing tooling can do. The business does not know what the numbers are until an outage happens, then experiences a mismatch with expectations.
- Setting them aspirationally. “RPO 15 minutes, RTO 1 hour” is easy to write and very expensive to actually deliver across all systems. Tier the systems and apply the right objectives to each tier.
Where Australian businesses get value
The most cost-effective improvements we see are usually:
- Adding immutability to existing backup destinations — sometimes a configuration change, sometimes a small additional cost.
- Separating the backup management plane from the production identity domain.
- Running an end-to-end recovery test of the most critical workload at least annually, ideally quarterly.
- Building a written DR runbook that someone other than the most senior engineer can execute under pressure.
What good looks like
A mature backup and DR posture has these properties: data is captured at a frequency aligned with business RPO; copies are stored across at least two media including one immutable; the backup environment is logically isolated from production; restores are tested regularly; and there is a written runbook that has been used in anger at least once. Anything less is a hope, not a plan.
If you would like an honest assessment of your backup and DR posture, including a tested-restore validation, we can help.