Account Contact Build your IT department

Learn / practitioner

What backups for a 30-person company actually look like

Most SMB backup setups look fine on paper and fail on the day they are needed. Here is what a defensible backup program looks like in 2026 — and the four specific failures that produce the recovery-day surprise.

If you ask the average IT director at a 30-person company whether they have backups, the answer is yes. If you ask the same person, on the day a CFO’s laptop dies with the only copy of next quarter’s financial model on it, whether they can produce that file from a backup, the answer is much less reliably yes.

The gap between “we have backups” and “we can recover what matters in the time we need it” is where most backup programs fail. Backup is one of those operational disciplines that looks easy in the proposal and turns out to be hard in practice — not because the tools are bad, but because the configuration, the coverage, and especially the testing are skipped or done badly. This piece walks the structure: what to actually back up, where to put the copies, how to know it works, and the specific failure modes that turn paid-up backup products into recovery-day disasters.

We will not pretend to be unbiased — we sell a backup product, two of them in fact — but the structural content here applies to any vendor. You should be able to evaluate ours and any competitor’s against the same checklist.

What needs backing up — and what you will forget

The standard answer is “files.” The accurate answer is broader. A defensible backup program in 2026 covers, at minimum:

  • Endpoints — laptops and desktops, every one of them. The CFO model on the laptop. The engineering team’s local working copies of code still sitting unpushed. The administrative assistant’s personal Outlook PST. All of it.
  • M365 / Workspace data — Exchange, OneDrive, SharePoint, Teams chats and channels, Google Drive, Gmail, Calendar, Contacts. We will come back to why M365’s built-in protection is a retention layer, rather than a backup.
  • Servers — if you still have any. File servers, application servers, domain controllers. Increasingly small companies have moved off on-prem; for any servers you still run, they need backing up.
  • SaaS application data — your CRM, your accounting system, your project-management tool. The “vendor takes care of it” assumption fails in specific, frequently-tested ways.
  • Configurations — your firewall rules, your network gear, your cloud IaC, your DNS zone files. Catastrophic loss of configuration is harder to recover from than loss of files; nobody remembers what was set on the firewall three years ago.
  • Encryption keys and credential vaults — if your password manager dies, you have lost access to everything in it. Including the password manager itself.

The pattern that fails: every category above except the obvious one. “We back up our files” is incomplete because files were rarely the failure mode that mattered most.

3-2-1 in 2026 — and why it has been quietly updated

The classic backup rule is 3-2-1: three copies of your data, on two different media, with at least one copy off-site. It came out of an era of tape backups and physical disks, but the structural logic survives — diversification of failure modes is the whole game.

Modern interpretation:

  • 3 copies — original + at least two backups. The two backups should not share a fate (e.g., not both on the same NAS).
  • 2 different media — at minimum, one local-fast copy and one cloud copy. The “media” definition has loosened from physical (tape, disk) to logical (different storage classes / providers / vaults).
  • 1 off-site — and increasingly, the modern read of this is “1 immutable, off-site, in a fate-isolated vault.” Ransomware-grade attackers will go for your backups specifically; a backup that lives on the same network as production fails the off-site test.

The 2024-era addition is the immutability requirement. The reason is direct: if your backups can be encrypted by the same ransomware that encrypted production, they are not backups, they are additional victims. Immutability — the property that even an authenticated administrator cannot change or delete the backup chain within the retention window — is now the standard expectation, especially from cyber-insurance underwriters (see our piece on cyber-insurance requirements for why).

So the 2026 version of 3-2-1 reads: 3 copies; on at least 2 different storage classes/providers; at least 1 off-site, immutable, and isolated from production credentials.

Why M365’s built-in protection is not a backup

This deserves its own section because the misconception is industry-wide. Microsoft 365 has retention policies, recycle bins, version history, and a 30-day Litigation Hold default. It is not a backup product. Microsoft has been increasingly explicit about this in their own documentation, but the SMB market keeps re-discovering it the hard way.

What M365’s built-in protection covers:

  • Accidental deletion within the recycle-bin window (30 days for most surfaces).
  • Version history within the document-versioning window.
  • Tenant-side disaster (Microsoft’s data-center failures, their problem to fix).

What it does not cover:

  • A user who empties the recycle bin and then realizes they needed the file. (Past 30 days, gone.)
  • An admin or compromised account that mass-deletes mail from someone else’s mailbox. (Undelete is unavailable past retention.)
  • Granular point-in-time restore — you cannot say “give me everyone’s mailbox as it was at 10:00 AM on Tuesday.”
  • SharePoint or Teams data destroyed by a misconfigured retention policy or aggressive lifecycle rule.
  • Ransomware that encrypts the OneDrive folder while it syncs to the cloud — version history can help but has limits, and attackers know to flood the version stack.

A defensible 2026 backup posture treats M365 as a production system and backs it up to an independent vault on its own retention policy. The independent vault might be Veeam-for-M365, Datto SaaS Protection, Synology ActiveBackup, AvePoint Cloud Backup, or — if you happen to be a goCloudOffice customer — 360M365Backup. The vendor matters less than the architectural property: backups are in a different system, on different credentials, with their own retention and immutability.

RTO and RPO without theater

Two metrics get thrown around in backup discussions: RTO (Recovery Time Objective — how fast you need to be back up) and RPO (Recovery Point Objective — how much data you can afford to lose). Both are commonly misused.

  • RTO is how long the business can tolerate the system being down, rather than “how fast can our backup product theoretically restore.” For a 30-person law firm, the practical RTO on email is hours, rather than days. For the CFO’s laptop, RTO is whenever they next need that quarterly model — could be a day.
  • RPO is how much data loss is acceptable for the system in question, rather than “the smallest backup interval the product offers.” For files, an RPO of 24 hours is usually fine; for an actively-edited financial model the day before the board meeting, the RPO is much tighter.

The pattern that wastes money: setting aggressive RTO/RPO targets on systems where the business has no real need for them, then paying for the premium-tier backup product to deliver those targets. The pattern that creates risk: setting loose targets and then discovering, on recovery day, that the business needed something tighter.

Real practice: differentiate. Email and CRM might need RPO 4 hours, RTO 8 hours. File shares might tolerate RPO 24 hours, RTO 24 hours. Engineering build environments might be re-creatable from source-control + CI in less time than a restore would take, so the backup target is documentation rather than data. Most SMBs end up with three or four tiers across their data estate, rather than one number for everything.

What “tested restore” actually requires

Underwriters and auditors increasingly want to see evidence of tested restores. The phrase has a specific meaning that often gets slid past:

  • A test restore is not “the backup product reports success.” That tells you the backup job completed. It says nothing about whether the data, when recovered, will be intact and usable.
  • A test restore is taking a backup chain, restoring it to an isolated environment, opening the recovered data, and verifying it can be used. For files: open them. For mailboxes: log in and read mail. For databases: spin up the database and run a query.

This costs time. A real test-restore drill on a 30-person company’s full environment is a multi-hour exercise. Most SMBs do this annually at most; the disciplined ones do it quarterly. The number that matters for insurance and audit purposes is “when was the last successful test restore, and what was tested?” — rather than “do we have backups.”

The pattern that fails on recovery day: backup product reports success for years, but on the day of need, restore fails because of credential rot, retention drift, or — in a real case we know of — the backup chain getting silently encrypted by a different copy of the same software running with old credentials.

The four failures that produce the recovery-day surprise

Specific patterns we have seen often enough to call out:

  1. Credential rot. The backup product authenticates to your environment with credentials that were valid when configured. Three years later, the service account password has been rotated, MFA was added, the account was disabled — and the backups have been silently failing for six months because the email alerts went unread. Fix: monitor the alerts the backup product emits, in addition to the dashboard, and re-validate credentials annually.
  2. Coverage drift. A new computer is added to the fleet but stays unenrolled in the backup product. A new SharePoint site is created and lives outside the backup scope. Six months later, that newly-created (and newly-loved) data is unprotected. Fix: backup-coverage audits tied to the device-onboarding and tenant-creation processes.
  3. The “backup is online” fallacy. Backups stored on a NAS or a cloud share that the production environment can write to are exposed to the same ransomware. Real isolation means immutable storage, separate credentials, retention policies the production tenant cannot modify. Fix: explicit immutability with a retention window matched to your worst-case detection-to-discovery delta (typically 90 days minimum).
  4. The single-product single-point-of-failure. All backups in one vendor’s system. If that vendor has an outage, gets compromised, or simply changes their pricing beyond what your team can absorb, you are stuck. Fix: at least one backup copy in a different vendor’s infrastructure, even if it is just the most-critical Tier 1 data.

How goCloudOffice handles backups

We sell two backup products and we will describe what they do honestly:

  • 360CloudBackupPro covers endpoints — laptops, desktops, configurations. Captures every 30 minutes to immutable cloud storage on its own credential plane. Granular point-in-time restore. Bare-metal recovery for full-computer rebuilds. Quarterly recovery-drill report (the test-restore evidence underwriters want).
  • 360M365Backup covers Exchange, OneDrive, SharePoint, and Teams data. Daily snapshots into independent storage; retention configurable to 7 years for compliance use cases. Restore to original location or alternate user; full mailbox or single message; full SharePoint site or single document version.

Both products are designed against the four failures listed above: credential rot is monitored at the platform level; coverage drift is caught by automated enrollment tied to the same device-management plane that handles the rest of the 360SmartIT Department subscription; immutability is the default, not the upsell; and the products are on different vendor infrastructure than production by design.

What stays outside our catalog: a server-backup product, because most of our customer base runs without on-premise servers. If you have on-premise infrastructure that needs backing up, we can scope it under Pro2 / Pro3 consulting using third-party tools (Veeam, Datto BCDR, Acronis), though it lives outside the per-computer subscription. If you have meaningful on-premise infrastructure, talk to us about how to think about its protection separately.

If you would like to walk through what backup coverage would look like for your specific environment, the build flow generates a scoped recommendation. Even without a subscription, the output is a useful checklist for evaluating your current setup.

Technically reviewed by Tobias Wexler.

Want this turned into a real plan?

The build flow uses the same logic this article describes — three minutes to a configured IT department.

Build your IT department Talk to us