The short answer: offsite backup vs. cloud backup is a false choice — cloud backup is a form of offsite backup, and the property that actually decides whether you survive ransomware is immutability plus a tested restore, not where the copy sits. The modern target is 3-2-1-1-0: three copies, two media, one offsite, one immutable or offline, zero restore-test errors. Everything below unpacks that.
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.
Why store backups offsite at all?
A backup that sits in the same building as the data it protects shares the data's fate. The reason backup media should be stored offsite is simple: anything that destroys the original can destroy a local-only copy in the same event. A fire takes the server and the backup appliance next to it. A flood ruins both. A burglar walks out with the workstation and the external drive in the same bag.
The threat that makes offsite mandatory today is ransomware. Modern attacks don't stop at the production data — they hunt for the backup, delete shadow copies, kill the backup service, and encrypt any backup the compromised network can reach. A local backup on the same network is often reachable, which means it gets encrypted too. An offsite copy that the attacker can't touch — especially an immutable one — is the copy that survives and lets you recover without paying.
So backup media should be stored offsite because offsite is the one copy that outlives a site-wide disaster or a network-wide attack. It is the difference between an inconvenience and a closed business.
How safe are offsite backups?
An offsite backup is only as safe as how it's configured. Location alone is not protection — a cloud copy the attacker can log into and delete is no safer than a local drive. Safety comes from a stack of controls:
- Encryption in transit and at rest — data is encrypted before it leaves your network and stays encrypted in storage, so a compromised link or a breached data center doesn't expose readable data.
- Access controls and MFA — the backup console and storage are protected by multi-factor authentication and least-privilege access, so stolen credentials don't hand over the backup.
- Immutability or object lock — the copy cannot be altered or deleted for a defined retention window, even with admin credentials. This is what stops ransomware from reaching across and wiping the offsite copy.
- Tested restores — a backup you've never restored is unproven. Safety includes confirming the data actually comes back, on a documented cadence.
Configured this way, an offsite backup is very safe — safer than the production environment it protects. Configured carelessly, it offers false comfort.
What offsite backup costs (and what drives it)
There's no single price for offsite backup, because the cost is driven by three things:
- Data volume — how much data you're protecting, and how fast it grows. A few hundred gigabytes costs less to store and replicate than several terabytes.
- Retention length — how far back you need to recover. Keeping daily restore points for years costs more than keeping a few weeks, and regulated industries often need longer retention.
- Restore-speed needs — a tight recovery-time target may call for a local appliance for fast restores plus immutable cloud for survival, which costs more than cloud-only.
At Micro-IT, restore-tested backup is part of the managed stack rather than a line item you assemble yourself — image-level local backup replicated to immutable cloud storage, with retention set to your regulatory and operational needs. The right number depends on your data and targets, so we scope it during onboarding. See our plans or call 270.816.5726 for a figure tied to your environment.
Does HIPAA or cyber insurance require offsite backup?
HIPAA does not use the word "offsite," but its Security Rule effectively requires it. The Contingency Plan standard at 45 CFR 164.308(a)(7) requires covered entities to establish a data backup plan — "procedures to create and maintain retrievable exact copies of electronic protected health information" — and a disaster recovery plan to "restore any loss of data." A backup that can't survive a fire or flood at the same site can't satisfy a disaster recovery plan, so a recoverable offsite copy is what meets the standard in practice. (Source: 45 CFR 164.308, Cornell Legal Information Institute.)
Cyber insurance is now more explicit. To bind or renew a policy, carriers increasingly require offsite, immutable, and regularly tested backups as a condition of coverage — alongside MFA and endpoint detection. Carriers have learned that recoverable offsite backups are what let a business decline a ransom, so they underwrite for it. If your backup isn't offsite and tested, you may be answering "no" on the application without realizing it.
