Most small business backup setups fail the same test. The backup runs, the dashboard is green, and then a file gets deleted in March and nobody can produce the version from February. Backup is only half the job. Restore is the half that gets tested on the worst day of the year.
Here is a setup that survives the four things that actually happen: a deleted file, a dead laptop, a ransomware event, and an auditor asking for proof.
Decide what you are protecting against
| Scenario | What saves you | What does not |
|---|---|---|
| Someone deletes a file | Version history and recycle bin retention | Nothing, if retention already expired |
| Laptop dies or is stolen | Files stored in the cloud, not only on the device | A local external drive left in the same bag |
| Ransomware encrypts everything | An immutable copy an attacker cannot delete | A backup reachable with the same admin login |
| A folder is quietly corrupted months ago | Long retention plus periodic restore testing | A 30 day retention window |
| Auditor asks for evidence | Documented restore tests with dates | A green dashboard screenshot |
Notice how often the failure is retention rather than the backup itself. Most businesses discover their retention window only after it has cost them something.
The structure that works
- Get files off individual devices. Company data belongs in SharePoint, OneDrive or Google Drive, not in a folder on a laptop desktop. If the data only exists on the device, backup is already a hope rather than a plan.
- Back up the cloud service itself. Microsoft 365 and Google Workspace protect their infrastructure, not your mistakes. Deleted items and version history have limits, and both expire. A third party backup of the tenant extends that.
- Keep one copy out of reach. Immutable, separate credentials, different administrator. If the account that runs your business can delete the backups, so can whoever compromises it.
- Set retention against your real risk. 30 days covers accidents. Twelve months covers quiet corruption, departed staff and disputes. Longer if you have a legal or contractual requirement.
- Test restores on a schedule. Quarterly, with the date and the elapsed time written down. An untested backup is a theory.
- Write down who does the restore. At 7am during an incident is not when you want to discover only one person has the credentials.
Two numbers to agree before you buy anything
How much data can you afford to lose? If backups run nightly, you can lose a day of work. If that is unacceptable for your finance folder, that folder needs more frequent protection. This is your recovery point.
How long can you be down? Restoring a single file takes minutes. Restoring a server to new hardware takes hours, and restoring a full environment can take days if the plan is improvised. This is your recovery time.
Both numbers are business decisions, not technical ones. Write them down, then size the solution to them. Every backup conversation that starts with product names instead of these two numbers ends in either overspending or a nasty surprise.
The mistakes we see most
- Sync treated as backup. File sync replicates a deletion and an encryption just as faithfully as it replicates a document.
- One account holding everything. Backup access should not share credentials with daily administration.
- Nobody reads the failure emails. Backup software is good at reporting failures and businesses are good at filtering those emails.
- Mailboxes excluded. Email is often the most contested data in a dispute and the most commonly left out of the backup scope.
- No documented restore. If you have never restored anything, you do not have a backup, you have an expense.
A quick self check
Answer these out loud. Where was the last restore you performed, and when? What is your retention period, in days, for files and for email? If your main administrator account were compromised tonight, could the attacker delete your backups? Who else can perform a restore if that person is unreachable?
Four confident answers means your setup is probably sound. Any hesitation shows you exactly which part to fix first.
How we structure and test this is on the cloud backup and recovery page. Related: cloud file sharing and access setup for getting data off devices in the first place, and IT assessment if you want the current state documented before changing anything.