Small Business Backup Strategy: Copies, Locks and Restores

A small business backup strategy answers three questions. What does the business need to keep running? Where do the copies live so that one incident cannot reach them all? And how quickly can a restore be done, by whom, from which copy?

This guide covers each part for an organisation of 10 to 250 people. It draws on the published advice of the US Cybersecurity and Infrastructure Security Agency (CISA), the UK National Cyber Security Centre (NCSC) and NIST, and on the providers' own documentation. Costs for Microsoft 365 backup products are compared separately in Microsoft 365 backup pricing: per user or per gigabyte, so they are not repeated here.

What a small business backup strategy has to cover

The NCSC's small organisations guide sets the scope plainly: back up "all the data that your business needs to operate". That is wider than the shared drive. It includes mail, finance records, customer details and the settings that make systems work.

CISA's small and medium business page gives a list worth copying into any plan. It names customer and client records, HR information, financial and payroll data, emails, "Configuration files and software settings", and website and operational databases.

Start with an inventory. List every system, who owns it, where its data lives and what happens to the business if it is gone for a day. That list drives every later choice, from how often to copy to what to restore first.

Laptops and desktops

Microsoft's Known Folder Move moves the Desktop, Documents, Pictures, Screenshots and Camera Roll folders into OneDrive. Microsoft says saving files to OneDrive "backs up your users' data in the cloud". It is a useful first step, because a lost laptop no longer means lost work.

It also moves the problem. The files now sit in Microsoft 365, and that service needs its own protection, covered in the next section. Device settings and encryption are endpoint questions, set out in endpoint security for small businesses.

Servers and line-of-business systems

For servers, a copy of the data is not enough. CISA's #StopRansomware Guide advises keeping and regularly updating "golden images" of critical systems. These are preconfigured templates of the operating system and applications, from which a server can be rebuilt quickly.

The same guide suggests storing installers, licence agreements and escrow documents with the offline backups. It also advises keeping backup hardware for rebuilding, because old equipment can cause compatibility problems during a restore.

Cloud services are still your data to protect

Moving to Microsoft 365 or Google Workspace hands the servers to the provider. It does not hand over responsibility for the data.

Microsoft's page on shared responsibility in the cloud lists "Customer data" as the customer's responsibility in all four models, including software as a service. It says: "For all cloud deployment types, you own your data and identities." Accounts and access management sit on the customer side too.

Google is just as direct about its own tooling. The Google Vault FAQ answers the question of whether Vault is a backup tool with "No. Vault isn't designed to be a backup or archive tool." It adds that "You might want a backup to protect your data against human error or ransomware attacks."

How long deleted data can be recovered

Both platforms keep deleted data for a short time. After that, it is gone.

The Drive figure comes from Google's page on recovering deleted Drive files, which adds: "You can't restore individual files or folders." The Gmail figure comes from its page on restoring permanently deleted email.

The equivalent Microsoft 365 windows, and what each backup option costs, are in the Microsoft 365 backup pricing comparison. Microsoft's own Microsoft 365 Backup covers SharePoint, OneDrive and Exchange. Microsoft says its data "never leaves the Microsoft 365 data trust boundary", so it is a separate copy in time but not in place.

The 3-2-1 rule as CISA and the NCSC state it

The best-known backup rule has two official wordings, and they differ slightly.

CISA gives "a hard drive and the cloud" as an example of two media types. The NCSC's 10 Steps data security page uses the same 3-2-1 wording as its offline backups article.

That article makes a point many summaries miss: 3-2-1 does not require any copy to be offline. Three connected copies can all be reached by one attacker. The NCSC's answer is to keep at least one copy offline at any given time, because then "an incident cannot affect all of your backups simultaneously."

Vendors and commentators publish longer variants of the rule. None of the CISA, NCSC or NIST pages read for this guide states one, so this guide treats "three copies, two kinds of storage, one off site, plus one copy offline or locked" as the working standard.

Why attackers go after the backups first

Backups are the reason an organisation can refuse to pay. Attackers know this.

CISA's #StopRansomware Guide warns that "many ransomware variants attempt to find and subsequently delete or encrypt accessible backups". The NCSC's ransomware guidance says the same in fewer words: "ransomware actively targets backups to increase the likelihood of payment."

Three habits make that easy for them:

• A backup drive left plugged in. The NCSC's small organisations guide says the device "should not stay connected" when not in use, because some malware spreads to attached devices.
• Sync mistaken for backup. The NCSC notes that "cloud services often automatically synchronise immediately after your files have been replaced with encrypted copies."
• One set of keys for everything. If the same administrator account runs the servers and the backups, stealing it reaches both.

The NCSC also says up-to-date backups are "the most effective way of recovering from a ransomware attack". The goal is to make sure at least one of them survives the attack.

Offline, immutable and locked copies

There are two ways to put a copy out of an attacker's reach. One is to disconnect it. The other is to store it somewhere that refuses to change or delete it for a set time.

Disconnected copies

A rotated external drive, kept unplugged and off site, is the simplest offline copy. The NCSC adds a warning: "You shouldn't rely on having two copies on a single removable drive."

Cloud storage cannot be unplugged, so the NCSC says it must be digitally disconnected instead. Its guidance is that backup software should not hold working credentials while the storage is idle. Where possible, the storage should "deny connection requests while the storage is not in use ('cold')."

Object lock and immutable storage

The main cloud storage providers can lock stored copies so that they cannot be changed or deleted until a set date. Backup software writes to the locked store, and the retention period is chosen in advance.

Amazon's Object Lock documentation describes a "write-once-read-many (WORM) model". In compliance mode, it says the only way to delete a locked object early is to delete the AWS account. Governance mode is weaker: a user with the bypass permission can remove the lock, and the console sends the bypass header by default.

Microsoft's immutable blob storage overview says an unlocked policy can be shortened or deleted, so it is for testing only. Microsoft recommends locking the policy "typically less than 24 hours" after setting it. It also says there is "no extra capacity charge for using immutable storage".

Backblaze's Object Lock page says that once Object Lock is enabled on a bucket it cannot be disabled. Its pricing page lists B2 storage as starting at $6.95 per TB per month, as of 14 Nov 2026, and does not mention a separate charge for Object Lock.

Microsoft 365 Backup takes a middle path. Microsoft describes its storage as append-only, but says "Deletion of the backups isn't blocked". It offers a 90-day grace period after offboarding and email alerts to a group of admins instead.

Recovery point and recovery time in plain terms

Two numbers decide how often to back up and how much to spend on fast restores. NIST defines both in SP 800-34 Rev. 1.

• Recovery point objective (RPO) is "The point in time to which data must be recovered after an outage." Put simply: how much recent work can the business afford to lose? A nightly backup means up to a day of lost changes.
• Recovery time objective (RTO) is, in NIST's glossary, the length of time a system can be in recovery before the outage starts to harm the business. Put simply: how long can people work without it?

Set both for each system on the inventory, with the person who runs that part of the business. The accounts system at month end and the marketing archive will not get the same answer.

CISA's performance goals give one reference point: "Back up critical operations systems in near-real-time". Other systems can run on a schedule that fits the RPO agreed for them. The RPO definition also explains why one backup a week is rarely enough for mail or finance.

Restore speed matters as much as backup frequency. A complete copy that takes a week to download misses a one-day RTO. Write the expected restore time beside each system, then check it in a test.

How long to keep each copy

Retention is the question most often left at the software's default. It decides how far back a restore can reach.

The NCSC's 10 Steps page says not to rely on a single rolling copy, and to "ensure your backups are kept for longer (at least a month)". CISA's small business page asks for the ability to roll back data "at least seven days if needed".

Those are floors. Ransomware, a quiet account takeover or a mistake by a leaver may go unnoticed for weeks. A useful pattern keeps daily copies for a month, weekly copies for a few months and monthly copies for a year or more, as storage allows.

Legal and contract rules may set their own retention periods for records such as payroll or client files. Those apply on top of the backup schedule. If personal data is lost or locked, reporting duties may also apply; see data breach notification deadlines by jurisdiction.

The NCSC's principles for ransomware-resistant cloud backups ask providers to let customers keep backups for a period that "aligns with their risk appetite". They also prefer retention by time over retention by number of copies. A rule of "keep the last 30 backups" can be flushed out in an afternoon by an attacker who triggers 30 bad ones.

Proving that a restore works

Every source read for this guide says the same thing: test the restore, not just the backup. CISA's performance goals put a floor on it: "Test backups and recovery on a recurring basis, no less than once per year."

CISA's small business page asks for tests that show the team "can rapidly restore data both fully and partially". The #StopRansomware Guide asks for tests of "the availability and integrity of backups in a disaster recovery scenario". A test that only confirms the job reported success does neither.

A workable routine for a small team:

1. Monthly: restore a handful of files and one mailbox to a separate location. Open them.
2. Quarterly: restore one complete cloud account or shared drive, and time it.
3. Yearly: rebuild one critical server or system from its image and backups, on spare hardware or an isolated network.
4. After any big change: test again when a system, provider or backup product changes.

Record each test with the date, what was restored, how long it took and what went wrong. That record is the evidence an insurer, auditor or client will ask for. It also shows whether the RTO set earlier is realistic.

The restore plan belongs in the wider incident response plan. CISA advises keeping a hard copy and an offline version of that plan, since the systems that hold it may be the ones that are down.

Locking down the backup console

The backup system holds a copy of everything, so its admin accounts are among the most valuable in the organisation.

The NCSC's 10 Steps page says to "Restrict access to credentials and servers used for backups because attackers may target your backups." Its ransomware guidance goes further. It says backup accounts should be protected with privileged access workstations and hardware firewalls. It also says "the MFA method should not be installed on the same device that is used for the administration of backups."

Practical steps that follow from that advice:

• Separate accounts. Use a backup admin account that is not a day-to-day user account and not the main domain or tenant admin. CISA's guide asks to "Separate administrator accounts from user accounts" in general.
• Strong sign-in. Turn on multi-factor sign-in for every backup console and cloud storage account. The NCSC's small organisations guide asks for 2-step verification on online backups; methods are compared in multi-factor authentication for small businesses.
• Few clients. The NCSC's offline backups article advises keeping backup clients to a minimum, so ordinary user devices cannot change cloud backups directly.
• Alerts on destructive actions. The NCSC's cloud backup principles ask services to raise alerts when "significant changes are made, or privileged actions are attempted". Send those alerts somewhere an attacker in the main mailbox cannot delete them.

Phishing is a common route to these accounts in the first place, so mail filtering and sender checks matter too. See the business email security guide.

A backup checklist, in priority order

The list below runs from the steps that remove the most risk to the ones that refine the plan. It is drawn from the published guidance cited above. It was not run against a live environment; the methodology page explains how this site separates reading from testing.

1. Write the inventory. Every system, its owner, where the data lives, and an agreed RPO and RTO.
2. Get one copy off site and out of reach. Either a disconnected drive in rotation or cloud storage with object lock in compliance mode or a locked policy.
3. Back up Microsoft 365 or Google Workspace separately. The provider's recycle bins are not a backup; compare options in the pricing comparison.
4. Separate and protect the backup admin accounts with multi-factor sign-in, and remove backup access from everyday accounts.
5. Set retention by time, with at least a month of history and longer for key systems.
6. Run a restore test this month, and put the yearly full test in the calendar.
7. Keep golden images and configuration exports for servers, firewalls and other critical systems.
8. Turn on alerts for deleted jobs, shortened retention and failed backups, and make someone responsible for reading them.
9. Store the restore plan offline, with contacts and recovery codes, beside the incident response plan.
10. Review the plan every year and after any change of provider, system or staff.

For organisations that need to show this work to a client or certifying body, security frameworks for small businesses explains how backup controls appear in the common schemes. Every guide and comparison in this topic is listed under backup and recovery.