Backup Planning for Small Businesses

Sync is not a backup

This is the most consequential misunderstanding in small-business data protection, so it belongs first.

File sync services — the ones that keep a folder mirrored across your devices and the cloud — are designed to make every copy identical. That is precisely the problem. If a file is deleted, sync deletes it everywhere. If a file is corrupted, sync propagates the corruption. If ransomware encrypts your files, sync obediently uploads the encrypted versions over the good ones.

A backup is different in one essential way: it keeps point-in-time copies you can return to. The question a backup answers is “what did this look like last Tuesday?” — which sync, by design, cannot answer.

Many sync services do include file version history, and that genuinely helps for an accidental deletion or a bad edit. But the retention window is often limited, restoring thousands of files individually is painful, and it does not cover a device that fails entirely. Treat version history as a convenience, not as your backup strategy.

What should be backed up

Work through this list explicitly. The items businesses miss are rarely the obvious documents.

• Business documents and files. Contracts, records, correspondence — wherever they actually live, including individual desktops.
• Customer records. Your CRM, booking system, or operations platform data.
• Accounting and financial data. Including local company files if your accounting software stores them on a machine.
• Email. Often assumed to be safe because it is in the cloud. See the note on cloud services below.
• Cloud application data. What lives in the software-as-a-service products you depend on.
• Your website and its data. Files, database, and configuration — and know who holds them.
• Device and system configuration. How machines and network equipment are set up. Rebuilding from memory is slow.
• Credentials and licence keys. Stored securely, and accessible if your primary systems are down.

How much can you afford to lose?

Two questions, in plain terms, determine what your backup setup needs to do. They have formal names, but the ideas are simple.

How much work can you afford to redo?

If your last backup was at midnight and something fails at 4pm, you lose a day of work. Is that survivable? For a business capturing a handful of records daily, probably. For one processing dozens of transactions an hour, no. Your answer sets how oftenbackups need to run. (This is what “recovery point objective” means.)

How long can you be down?

If your main system failed this morning, how long before the business genuinely suffers — hours, a day, a week? Your answer sets how fast recovery must be, which drives where backups are stored and how they are restored. Retrieving several hundred gigabytes over a slow connection takes longer than most people expect. (This is “recovery time objective.”)

These answers can differ per system. Your accounting data might tolerate a day of loss; the system your staff use hourly might not. Set them separately rather than applying one standard to everything.

Local, cloud, and offline copies

The widely used shorthand is 3-2-1: keep at least three copies of important data, on at least two different types of storage, with at least one copy off-site. It is a rule of thumb rather than a standard, and it remains a sound starting point.

• Local backups — an external drive or network device. Fast to restore from, which matters for a failed machine. Vulnerable to theft, fire, and to ransomware that reaches connected storage.
• Cloud backups — off-site by nature, protected from local disasters. Restoring large volumes takes longer.
• Offline or immutable copies — a disconnected drive, or cloud storage configured so backups cannot be altered or deleted for a set period. This is the copy that survives a serious incident.

For most small businesses, a sensible arrangement is a local backup for speed, a cloud backup for off-site protection, and immutability enabled where the provider supports it.

Ransomware changes the math

Modern ransomware deliberately targets backups, because attackers know that a business with working backups has far less reason to pay. It is common for attackers to spend time inside a network first, locating and destroying or encrypting backups before triggering anything visible.

That has two practical implications:

• A permanently connected backup drive is not enough. If your computer can write to it at any time, so can ransomware running on that computer.
• Backup credentials must be separate. If your everyday administrator account can delete backups, then a compromise of that account is a compromise of your recovery.

This is what makes offline or immutable copies worth the modest extra effort. CISA’s Stop Ransomware resources go into depth here, and the recovery guidance consistently comes back to backups that attackers cannot reach.

Protecting the backups themselves

Backups contain everything your live systems contain, which makes them a target in their own right — an unprotected backup is a complete copy of your business waiting to be taken.

• Encrypt them, in transit and at rest, and store the encryption keys somewhere you can reach during an incident.
• Restrict who can access and delete them, using accounts separate from everyday administration.
• Enable multi-factor authentication on the backup service.
• Set retention deliberately. Long enough to recover from a problem discovered weeks later; not so long that you are indefinitely storing data you should have deleted, which works against minimizing what you hold.
• Monitor that they are running. Silent failure is common — a job that stopped months ago looks exactly like one that never ran.

Testing restoration

This is where most backup strategies actually fail. Backups that have never been restored are an assumption. Common unpleasant discoveries: the job excluded an important folder, the database backed up in a state it cannot be restored from, the restore takes three days rather than three hours, or nobody knows the credentials.

A simple recovery exercise

Twice a year, take an hour and do this:

1. Pick a real file from a few weeks ago and restore it. Time it.
2. Restore a full system or database to a test location — not over the live copy — and confirm it opens and contains what it should.
3. Have someone other than the usual person attempt it, using only written instructions.
4. Write down what went wrong, how long it took, and what was missing.

That last point is the real value. If recovery depends on one person’s memory, you do not have a recovery plan — you have a single point of failure who also takes holidays.

Who is actually responsible

Two gaps recur. Employee devices: if people keep work files on their own laptops, those files are probably not backed up. The better fix is usually to keep work data in a central system rather than trying to back up every personal device.

Vendor boundaries: if a provider hosts your website or runs your line-of-business software, establish in writing what they back up, how often, how long they keep it, how quickly they can restore, and whether you can obtain your own copy. Assumptions here are frequently wrong, and the moment you discover it is the worst possible moment.

Finally, name a person accountable for backups working. Systems without an owner drift, and backups drift silently.

Backup checklist

If you do only one thing after reading this: restore something. Not check that the job says “successful” — actually restore a file and open it. That single test tells you more than any amount of configuration review.