Backups That Actually Work When You Need Them

Most small businesses have something they'd describe as a backup. Considerably fewer have one that would work.

The failure is almost always silent: a job that stopped running months ago, a drive that was full, a sync that faithfully replicated the deletion, or a backup that was connected when the ransomware ran.

Sync is not backup

The most common and most costly misunderstanding.

Cloud sync — the folder that mirrors to a cloud service — is designed to make the same files appear everywhere. That's the opposite of what a backup does.

Delete a file and it deletes everywhere. Encrypt it and the encrypted version syncs. Corrupt it and the corruption propagates. Sync faithfully replicates whatever happened, including the things you needed protection from.

Most sync services keep version history, which helps — but it's typically limited in duration, awkward to restore at scale, and not designed for recovering thousands of files at once.

Sync is convenience. Backup is a separate, versioned copy you can restore from a point in time. You want both, and they aren't the same product.

3-2-1

The rule worth actually following:

• Three copies of anything that matters
• Two different media or services
• One off-site and disconnected

The disconnected part is what makes it work against the realistic worst case. Ransomware encrypts everything it can reach — including the external drive plugged in permanently, and in some cases the network share and connected cloud storage.

A backup that's always attached is a backup that gets encrypted with everything else.

In practice for a small business:

Copy 1:  Working data on your machines / main systems
Copy 2:  Automated cloud backup service (versioned, separate from sync)
Copy 3:  Periodic copy to an external drive, DISCONNECTED between backups

Decide two numbers first

Everything else follows from these, and most people have never stated them.

How much data can you afford to lose? If backups run nightly, a failure at 4pm loses a day's work. Is that acceptable? For accounting data, probably. For active client work, possibly not.

How long can you be down? Restoring hundreds of gigabytes over a domestic connection takes longer than people expect. If you need to be working within four hours, an off-site-only backup may not meet that.

Write both down. They determine backup frequency, and whether you need a local copy for speed alongside the off-site one for safety.

Back up the things people forget

The obvious files are usually covered. These frequently aren't:

Email. If your provider is your only copy, an account compromise or accidental mass deletion can be unrecoverable. Most providers keep deleted items briefly, not indefinitely.

Accounting data. Cloud accounting is not automatically backed up in a form you control. Check whether your provider offers export, and take periodic exports regardless.

Your website. Both files and database. Hosting backups are common and shouldn't be your only copy — if the hosting account is the thing you lose, so are the backups in it.

SaaS data generally. CRM records, project data, support history. Providers protect against their failures, not against you deleting something or losing account access. Check what export exists.

Configuration. DNS records, integrations, the settings someone spent two days getting right. Rarely large, occasionally painful to reconstruct.

Test the restore

The step that separates real backups from assumed ones.

Every quarter, restore something real. Not "check the backup ran" — actually restore a file, a folder, or ideally do a test restore of something substantial, and confirm it opens and is current.

What this catches, routinely:

• Backups that stopped running months ago and never alerted anyone
• Backups running but excluding an important folder
• Corrupted or incomplete archives
• Nobody knowing the credentials to restore
• A restore taking far longer than anyone assumed

The number of businesses that discover their backups were broken at the exact moment they needed them is not small, and it's entirely preventable with a quarterly fifteen minutes.

Put it in the quarterly planning cycle so it happens.

Monitor for silence

Backups fail quietly, which is the whole problem.

• Turn on success and failure notifications, and make sure they go to someone who reads them
• Better: notice absence. A missing success notification should be as noticeable as a failure one, because a job that stopped running sends neither
• Check the backup size occasionally. A sudden drop means something stopped being included

This is the same silent failure problem as any automation: the dangerous mode isn't loud breakage, it's quiet non-operation.

Write down how to restore

At two in the morning during an incident is not when you want to work out the process.

One page, stored somewhere that survives the failure — printed, or in a different system:

BACKUP RECOVERY

What's backed up, where, how often:
Access credentials location:
Restore steps:
  1.
  2.
Expected restore time:
Who to call:

Store it somewhere that isn't the thing that failed. A recovery document only available on the encrypted server is not available.

The mistakes

1. Assuming sync is backup. It replicates the problem faithfully.
2. Backups permanently connected. Encrypted along with everything else.
3. Never testing a restore. An assumption, not a backup.
4. No failure alerting — or worse, no alert on absence.
5. Forgetting email, SaaS data and configuration.
6. Recovery instructions stored only on the system that failed.

What to do next

Restore one real file from your backup this week. If you can't — because you don't know the credentials, the job stopped running, or the file isn't there — you've just learned something important at the cheapest possible moment.

Then set a quarterly reminder to do it again.