Business Backup Strategy: The 3-2-1 Rule and Why It Still Matters

“We have backups” is one of the most common and least reliable statements in small business IT. Most of the time, backups exist. Some of the time, they’re working. Rarely have they been tested. Occasionally, when they’re needed most — during a ransomware incident or a major hardware failure — they turn out to be missing, corrupted, or inaccessible.

A credible backup strategy isn’t complicated, but it does need to be deliberate. This post covers the durable principles that should shape every Australian SMB’s backup program.

The 3-2-1 rule

The 3-2-1 rule is thirty years old and still the baseline every backup strategy should satisfy:

• 3 copies of your data
• On at least 2 different types of media
• With 1 copy offsite

The logic is straightforward: any single point of failure — a corrupted drive, a failed backup server, a ransomware attack, a burst pipe in the office — shouldn’t be able to destroy every copy of your data. Three copies on different media with one offsite survives almost any single event.

In practice, a typical SMB 3-2-1 setup looks like:

• Copy 1: your live data on the production server / M365 / SaaS
• Copy 2: daily backup to a local NAS or backup appliance
• Copy 3: offsite backup to cloud storage (Azure, AWS, or a backup vendor’s cloud)

That’s the minimum credible baseline.

What modern ransomware changed

The 3-2-1 rule predates modern ransomware. Attackers now routinely:

• Compromise the backup system before triggering encryption
• Delete backup snapshots
• Corrupt or encrypt the backup data itself

If your “offsite” backup is accessible over the network with credentials an attacker can compromise, it’s not really protected. Ransomware gangs specifically hunt for backup systems as part of their reconnaissance phase.

This changed the recommendation. Modern backup strategy is often phrased as 3-2-1-1-0:

• 3 copies
• 2 media types
• 1 offsite
• 1 immutable or air-gapped
• 0 errors (backups have been verified)

The extra “1” — an immutable copy — is the real ransomware defence.

What immutable backups mean

An immutable backup is one that can’t be altered or deleted, even by an administrator, for a defined retention window (e.g., 30 days). Even if an attacker has full control of your environment — domain admin, backup admin, cloud admin — they can’t touch the immutable tier.

Common ways to achieve immutability:

• Hardened Linux repositories (Veeam Hardened Repository, similar): a dedicated Linux server with file-level immutability that the domain can’t reach
• Immutable S3 object lock (AWS, Wasabi, Cloudflare R2, Azure Blob with WORM): cloud storage where objects can’t be deleted until the retention window expires
• Dedicated appliances (Cohesity, Rubrik): vendors whose whole design assumes ransomware
• Tape backup: unfashionable but genuinely air-gapped once ejected

For most SMBs, immutable cloud storage or a hardened Linux repository is the right choice. Tape makes sense in specific scenarios — legal holds, regulated archives.

What to back up

Obvious candidates that get covered:

• File servers and shared drives
• Database servers (with proper application-consistent backup, not just VM snapshots)
• Virtual machines

Commonly missed but critical:

• Microsoft 365 data — Microsoft does not back up your tenant. Mail, OneDrive, SharePoint, and Teams all need separate backup (Veeam 365, AvePoint, Datto, similar). This is the single most common gap we find.
• Google Workspace data — same logic as M365.
• SaaS data — Xero, MYOB, Salesforce, HubSpot. Most have limited built-in backup; third-party backup products exist.
• Device configurations — network equipment configs, server configurations, Group Policy. Backup these too.
• Documentation and runbooks — if the only copy of your disaster recovery plan is in the tenant that’s been ransomed, that’s a problem.

How often to back up (RPO)

Recovery Point Objective (RPO) is how much data you can afford to lose if something goes wrong. A weekly backup means up to a week’s data loss; a continuous backup means minutes of loss.

Typical SMB targets:

• Production file servers: daily minimum, often twice daily
• Business-critical databases: hourly transaction log backups, daily full
• M365 mail and files: multiple times per day
• Archive data (rarely changing): weekly or monthly

Don’t assume longer retention automatically needs more frequent backups. Daily for 30 days is often more useful than hourly for 7 days.

How fast you need to restore (RTO)

Recovery Time Objective (RTO) is how long you can be down before the business impact becomes material. Different systems have different RTOs:

• Email: usually hours, not days
• File shares: usually hours
• Line-of-business apps (CRM, accounting): hours to a day
• Archive data: days is often acceptable

A backup system that meets the RPO but can’t restore fast enough to meet the RTO fails in the same way as no backup. Large VM restores from cloud backup can take many hours at consumer bandwidths.

Practical tactics to reduce RTO:

• Keep local copies alongside cloud copies (cloud as the ransomware defence, local as the speed layer)
• Use virtual DR — restore a VM to a cloud-hosted recovery environment, run from there during incident
• Pre-build runbooks for the most critical restore scenarios

Test, test, test

The single biggest cause of failed recoveries is: backup ran, backup was never tested, backup turned out to be unusable when it was needed.

Practical testing discipline:

• Monthly spot restores. Pick a random file from a random backup and restore it to a test location. Verify it works.
• Quarterly full restore tests. Restore a full server or a critical M365 mailbox to a test environment. Document how long it took.
• Annual DR exercise. Test the whole recovery path for a critical system, start to finish. Record lessons learnt.

Restores that work in tests aren’t guaranteed to work in real incidents, but restores that have never been tested are guaranteed to surprise you.

The bottom line

A durable backup strategy for an Australian SMB is:

• 3-2-1-1-0: three copies, two media, one offsite, one immutable, zero errors
• Includes M365 alongside servers and SaaS — Microsoft doesn’t back up your tenant
• Has defined RPOs and RTOs per system class
• Is regularly tested, not just hoped about
• Survives ransomware via the immutable tier

Most SMBs have some of these pieces. Few have all of them. A focused month of backup improvement work usually pays back the first time something goes seriously wrong — and eventually something always does.

If you’d like a review of your current backup coverage and testing discipline, get in touch. We’ll walk the environment, map what’s covered and what isn’t, and give you a prioritised list of changes. Cost is modest; the peace of mind is substantial.