The terms, untangled
Three words get used loosely. They're not the same thing:
- Local backup — a copy stored on-site: a backup appliance, a NAS, an external drive. Fast to restore from; useless if the building burns or the appliance is stolen or encrypted.
- Offsite backup — a copy stored at a different physical location. Historically a tape or drive driven to another building. Survives a site disaster.
- Cloud backup — a specific kind of offsite backup where the copy lives in a cloud provider's data center (AWS, Azure, Wasabi, Datto Cloud, Backblaze). All cloud backup is offsite; not all offsite backup is cloud.
The question "offsite vs cloud" is slightly the wrong question. Cloud is a way to do offsite. The real questions are: do you have a local copy for speed, do you have an offsite copy for disaster survival, and is at least one copy immutable so ransomware can't delete it?
The 3-2-1 rule (and the modern update)
The long-standing rule:
- 3 copies of your data (the production copy plus two backups).
- 2 different types of media (so a single media failure can't take both).
- 1 copy offsite (so a site disaster can't take everything).
The modern update, 3-2-1-1-0, adds two elements that ransomware made necessary:
- 1 copy immutable or air-gapped (cannot be altered or deleted for a retention period, even with admin credentials).
- 0 errors on the last restore test (because an untested backup is hope, not a plan — see backup is the answer; restore is the test).
Why immutability beats location
Here's the failure mode that catches small businesses: they have a cloud backup, they feel safe, and then ransomware encrypts everything anyway — including the cloud backup.
Modern ransomware doesn't just encrypt the primary data. It hunts for the backup first. It deletes Windows shadow copies, terminates the backup service, and — critically — if it can authenticate to your cloud backup (because the credentials are stored on the compromised machine), it deletes that too. A cloud backup that the attacker can log into and delete is not protected just because it's "in the cloud."
Immutability is the defense. An immutable backup cannot be modified or deleted for a defined retention window — not by the attacker, not by a rogue admin, not by anyone, until the retention expires. That's the property that makes the backup survive the attack. Location (local vs. cloud) is secondary to immutability.
The recommended small-business architecture
For most small businesses, the right backup is a hybrid:
- Local appliance — a backup appliance on-site that takes image-level backups of servers and critical workstations on a frequent schedule (every 1–4 hours for servers). This is your fast-restore copy.
- Immutable cloud copy — the local appliance replicates to immutable cloud storage on a daily (or more frequent) cadence. This is your disaster-survival and ransomware-proof copy.
- SaaS backup — a separate backup of Microsoft 365 or Google Workspace (mail, OneDrive/Drive, SharePoint, Teams). The cloud productivity suite is not backed up for you in the way owners assume.
This gives you: minutes-to-hours restore for routine failures (from the local appliance), survival of a site disaster (the cloud copy), and survival of ransomware (the immutable cloud copy plus immutable local snapshots).
Restore speed: the number that actually matters
Backups are measured by two numbers nobody talks about until they need them:
- RPO (Recovery Point Objective) — how much data can you afford to lose? If backups run every 4 hours, your RPO is 4 hours — you could lose up to 4 hours of work.
- RTO (Recovery Time Objective) — how fast can you be back up? Restoring a 2TB server from the cloud over a typical business internet connection can take a day or more. Restoring from a local appliance can take minutes to a few hours. This is why the local copy matters even when you have cloud.
Set both targets deliberately. A medical clinic that can't see patients without the EHR has a tighter RTO than a back-office that can wait a day. The backup design follows from the targets, not the other way around.
The Microsoft 365 blind spot
The single most common backup gap we find: businesses assume Microsoft backs up their 365 data. Microsoft does not, in the sense owners mean. Microsoft operates a shared-responsibility model — they keep the service available and protect against their own infrastructure failures, but recovering your data from accidental deletion, malicious deletion (a departing employee), or ransomware is your responsibility. Native retention is short.
A separate SaaS backup of Microsoft 365 (and Google Workspace) — mail, OneDrive/Drive, SharePoint, Teams — is a baseline control. The same is true for any cloud LOB application that holds data you can't afford to lose.
How a Micro-IT plan handles backup
Every Micro-IT environment gets image-level backup on servers and critical endpoints to a local appliance, replicated to immutable Datto cloud storage, with retention set per the client's regulatory and operational needs. Restores are tested on a documented cadence (not just scheduled). SaaS backup of Microsoft 365 mailboxes is included in Managed Inbox. RPO and RTO targets are set with the client at onboarding and reviewed quarterly. See backup is the answer; restore is the test for the testing discipline, or the security page for the full stack.
