Backup strategy for cloud-first businesses: what Microsoft does not do

The shared responsibility gap

The most common misconception in small business IT is that data in Microsoft 365 is inherently backed up. Microsoft replicates your data across datacentres — but that replication exists so the service stays available, not so you can recover a folder someone deleted in March. If a file is deleted, the deletion replicates perfectly to every copy.

Microsoft states this openly in its shared responsibility documentation: they are responsible for the platform, you are responsible for your data. The features that look like backup — recoverable items, the recycle bin, retention policies, version history — are recovery conveniences with defined limits, not a restore capability.

What the built-in features do and do not cover

Deleted mail moves to Deleted Items, then to Recoverable Items, and is typically retrievable for around fourteen days by default, extendable to thirty. SharePoint and OneDrive use a two-stage recycle bin totalling around ninety-three days. Version history lets you roll a document back through previous versions.

Those cover the ordinary cases well: someone deletes a file on Tuesday and needs it on Wednesday. They cover the serious cases poorly. Ransomware that encrypts a synced OneDrive folder repeatedly can exhaust version history. A departing employee who deliberately deletes material and empties the recycle bin before leaving can put it beyond reach. A problem discovered six months later — a dataset quietly corrupted, a mailbox purged during off-boarding — is past every window.

Retention policies are a separate mechanism and are often confused with backup. They prevent deletion of items within their scope, which is valuable for compliance, but they do not give you point-in-time restore of a site or mailbox and they are not designed for bulk recovery.

Applying 3-2-1 to a cloud-first business

The old rule still holds: three copies of your data, on two different media or platforms, with one copy off-site. For a business whose data lives in Microsoft 365, the translation is that the production copy in Microsoft 365 is copy one, a third-party backup in a different provider's infrastructure is copy two, and an export or an immutable archive is copy three.

The principle that matters most is provider independence. A backup that lives inside the same Microsoft tenant it protects fails in the scenarios that matter — a tenant-level compromise, an account takeover with administrative rights, or a billing lapse that suspends the tenant. If the attacker who reached your data can also reach your backup, you do not have a backup.

Immutability is the ransomware-specific control: backups that cannot be altered or deleted for a defined period, even by someone holding valid administrative credentials. Modern ransomware operators specifically hunt for and destroy backups before encrypting, so this is not a theoretical refinement.

• Keep at least one copy outside the Microsoft tenant it protects
• Prefer immutable or write-once retention for ransomware resilience
• Cover Exchange Online, SharePoint, OneDrive and Teams — Teams data is spread across several services
• Do not forget data outside Microsoft 365: your CRM, accounting system and website
• Document who can trigger a restore and how they prove who they are

Recovery objectives, set honestly

Two numbers define a backup strategy. Recovery point objective is how much data you can afford to lose, measured in time — a daily backup means up to a day of work is at risk. Recovery time objective is how long you can afford to be without the data.

Set these per system rather than globally, because they differ enormously. Email might be near-zero tolerance. A shared archive of old projects might tolerate a week. Setting a single aggressive objective across everything is expensive and usually theatrical.

Then test whether the objectives are real. Most businesses that state a four-hour recovery time objective have never attempted a restore and have no basis for the figure.

Testing: the part everyone skips

An untested backup is an assumption. The failure modes are mundane and common: the backup silently stopped working after a permissions change, a newly added SharePoint site was never included in scope, the restore requires credentials only one person had, or the full restore takes four days when the plan assumed four hours.

Test quarterly, and make it a real test. Restore an actual file to an actual location and confirm the contents. Once a year, run something larger — a full mailbox or a complete site — and time it. Write down who did it, what was restored and how long it took. That record is what you will hand to an insurer or an auditor, and it is the only honest basis for your stated recovery objectives.