Small Business Backups: What to Keep, Where, How to Test

calendar Oct 17, 2026 / · 11 min read · backup strategy small business it data backup disaster recovery restore testing ransomware protection cloud backup offsite backup it fundamentals  ·
Share on: linkedin copy

Most small-business backup plans rest on three assumptions nobody has checked: that the job covers the data the business runs on, that at least one copy sits somewhere a fire or an attacker can't reach, and that the copy can be restored into a working system. Most small businesses only find out which assumption was wrong during an outage, when a stolen laptop, a failed drive, or a ransomware attack turns a nightly green checkmark into a system nobody can recover.

This guide works through what belongs in a small-business backup beyond a vague "everything," where those copies need to sit to survive both a local disaster and a targeted ransomware attack, and the restore-testing habit that is the only way to know, before an emergency rather than during one, whether any of it works.

What Needs to Be Backed Up

The honest starting point is that "what to back up" looks different depending on how the business is built, not a single checklist that applies everywhere. NovaBackup's implementation guidance lays out five distinct real-world shapes: a small office running a server for five to twenty employees, which needs a local backup to an internal drive or NAS plus a nightly cloud job; a business in a regulated field like healthcare, legal, or financial services, where HIPAA and similar rules dictate documented retention periods, encryption in transit and at rest, and sometimes a formal Business Associate Agreement with the backup provider; a remote or hybrid team, where endpoint backup software has to run on every device regardless of location, because devices outside the office network are the ones that get missed entirely; a business running virtual machines, which needs software built to capture a proper point-in-time snapshot of each VM rather than a generic file copy; and a single-workstation "micro-business," which still needs the same three-copies, two-media, one-offsite coverage as a larger shop, just executed at a smaller scale.

Inside any of those shapes, the categories that matter most are the ones a business genuinely cannot operate without: financial and accounting records, customer and client data including whatever database or line-of-business application holds it, the configuration behind systems like a point-of-sale terminal or a CRM, and email and other communications. Losing any one of those doesn't just cost files — it stops the business from billing, shipping, or answering the phone.

How long those backups need to be kept matters as much as what's in them. Acronis's own guidance puts a number on it: small and midsize businesses should generally keep full system backups for at least two months, because that retention window is what lets a business restore a clean copy if needed and recover safely from malware that sat undetected on a system for a while before it was noticed. EverydayBackups frames the same need from the version-history side: a complete plan keeps 30 or more days of version history, specifically because ransomware and accidental deletions aren't always discovered the day they happen, and a shorter retention window closes off the option to roll back to a clean point before anyone realized there was a problem.

Where the Copies Need to Live

Once the "what" is settled, the classic structure for the "where" is the 3-2-1 rule: three copies of any important file (one primary and two backups), on two different media types, with one copy stored offsite. The US government's own Data Backup Options paper, produced for US-CERT and now hosted by the Cybersecurity and Infrastructure Security Agency (CISA), sets out the rule in exactly those terms and traces it to a 2009 digital-asset-management handbook. A fuller walkthrough of that rule and how it maps onto NAS, cloud, and offsite tools for a small team lives in our earlier look at the 3-2-1 backup rule; the part that matters here is what counts as meeting the "offsite" requirement, because it's the one most setups quietly fail.

NovaBackup is specific about the bar: a legitimate offsite copy has to be physically separate (a different building, data center, or cloud environment entirely), network-isolated (not directly reachable from the same network an attacker could already be on), and independently recoverable (restorable even if the main office and its systems are completely unavailable). A second hard drive plugged into the same computer doesn't qualify. A NAS device sitting in the same office doesn't qualify. Neither does a cloud folder that syncs directly to production files in real time, because a sync mirrors whatever state the files are currently in: if a file gets encrypted or deleted, that change replicates to the "backup" within seconds. The CISA paper makes the same warning about rolling backups in general, which "can silently propagate any corruption or malware in the primary files to the backup files." EverydayBackups makes the same point about a closely related mistake: RAID protects against a single drive failure inside one machine, but it does nothing against ransomware, accidental deletion, fire, or theft, and shouldn't be counted as one of the three copies at all.

The reason the isolation requirement has gotten stricter rather than looser is that ransomware now actively hunts for backups before it triggers encryption. In Sophos's survey of organizations hit by ransomware, 94% said the attackers tried to compromise their backups during the attack, and across all sectors 57% of those attempts succeeded. That's the logic behind the extra digits some vendors now add to make it "3-2-1-1-0": one additional copy that is offline or immutable, meaning no network-connected process, including a compromised admin account, can alter or delete it within its retention window, plus zero errors on a verified restore. CISA's #StopRansomware Guide puts the same requirement plainly: maintain offline, encrypted backups of critical data, and regularly test their availability and integrity in a disaster recovery scenario. A backup reachable from the production network is just as reachable to an attacker who's already inside it.

How to Test a Restore

A green backup dashboard answers less than it looks like it answers. Cloudswitched's guide breaks a backup job into three separable properties: that it ran, that what it wrote is internally consistent and readable, and — the only one that matters on the day it's needed — that the data inside can be put back into a working system, in the right shape, within a time the business can absorb, by the people who will be on shift. A green dashboard is evidence of the first property, weak evidence of the second, and no evidence at all of the third.

That's the gap between automated backup verification and an actual restore test, and the two aren't interchangeable. Automated verification runs nightly on its own and proves the archive is readable, but it has no way to catch the failures that live outside the backup product itself — an expired service account, a reclaimed software license, a DNS record nobody owns, a dependency the restored system needs but doesn't have. Cloudswitched's own assessment data makes that concrete: 62% of first restore tests surface at least one blocker of exactly that kind. A structured restore test, by contrast, is scheduled, attended, and walks the full recovery path end to end — which is also the only way to produce an actual measured recovery time rather than a number copied from a continuity-plan document. Cloudswitched's figures show why that distinction is worth the effort: among the UK businesses it assessed, only 1 in 5 could evidence a full, business-validated restore test within the previous 12 months, the recovery time measured on a first test typically ran 3.4 times longer than what the written continuity plan claimed, and the median cost of downtime for a 50-seat professional-services firm ran £4,300 per hour once lost staff time and deferred revenue were counted.

"Business-validated" is doing real work in that first stat, and it's worth being precise about. Cloudswitched defines it as a person who uses the system in their job opening the restored copy, performing a representative task, and confirming in writing that the data is complete and current to the expected point in time — an engineer confirming a VM booted doesn't count, and a file simply appearing in a folder doesn't count either, because both of the restore failures that cause the most damage (silently incomplete data, and a recovery point older than anyone realized) are invisible to the person running the restore and immediately obvious to the person who uses the data.

Stackrail's restore-testing guide turns that distinction into a concrete cadence: a restore drill for critical data at least quarterly, monthly if the data is regulated or changes heavily; the restore has to go to a separate environment and never overwrite production as the test itself; and the check afterward has to go past "the instance became available" into row counts, an application login, and a sample query. The exercise should be timed against the business's recovery time objective (RTO) and should note the actual recovery point objective (RPO) achieved from wherever the restore point landed — the gap between the two numbers on the page and the two numbers in reality is the whole point of running the drill. Stackrail's own guide illustrates the failure mode it's built to catch: a team that trusted its automated snapshots until a bad migration forced an actual restore, only to discover the needed backup window itself was corrupted, forcing a fallback to an older copy and the loss of hours of data — the exact gap a quarterly restore into a scratch instance would have surfaced ahead of time. Its recommendation is to script the restore and the smoke checks so the process doesn't depend on one person's memory, and to keep the date of the last successful drill logged next to the backup policy itself.

Turning This Into a Routine a Small Business Can Keep Up

The cost side is small. Cloudswitched's UK data puts the compute cost of an isolated restore test at tens of pounds, set against its own £4,300-an-hour downtime median for a 50-seat firm. The real constraint is staff attention — a named engineer for a day, a named business user for an hour, and a manager willing to protect both slots from getting reassigned to something more urgent.

Cloudswitched's most useful practical step costs nothing but a few minutes and happens before the first test ever runs: write down what the business currently believes its recovery time is for its two or three most critical systems, and get the person who owns each system to sign off on that number. The gap between that belief and the number a real restore test measures is, by Cloudswitched's own account, the single most useful output of a first testing cycle — and it only exists if the belief gets written down before the evidence arrives.

From there, the sequence follows naturally from everything above: identify the two or three systems whose loss would stop the business — likely the financial records, the customer database, or the line-of-business application named earlier — confirm the backup covering them satisfies the offsite and isolation bar, and put a restore drill for those specific systems on the calendar before anything else. A monthly single-file restore and a quarterly full restore, each logged with its date, scope, and result, is a modest routine next to the alternative of finding out the hard way.

Key Takeaways

  • What to back up isn't a universal checklist — it depends on the business's shape (single workstation, small office server, regulated industry, remote team, or VM environment), but financial records, customer data, and line-of-business application configuration top the list in every case.
  • A genuine offsite copy has to be physically separate, network-isolated, and independently recoverable; a second drive in the same machine, a NAS in the same office, or a real-time cloud sync don't qualify, and neither does RAID.
  • Ransomware hunts backups: 94% of organizations in Sophos's survey that were hit by ransomware said attackers tried to compromise their backups, and 57% of those attempts succeeded, which is why CISA calls for offline, encrypted copies.
  • A green backup dashboard proves the job ran and is weak evidence the data is intact — it proves nothing about whether the system can be restored to use, which only a scheduled, attended restore test can show.
  • Write down the believed recovery time for your most critical systems before the first restore test; the gap between that number and the measured one is the most useful thing a first test produces.

References

Posts in this series