Ransomware rarely arrives with a warning. By the time the ransom note appears on a Monday morning, the attacker has often been inside the network for days, mapping file shares, reading email, and locating the backups before deleting them. Small businesses get hit for the same reason they are attractive targets: fewer people around to notice odd behaviour, and often one person holding all the keys.
A backup plan that survives this is not complicated. It is specific. Here is a practical way to build one, using tools you probably already have, plus the checks most teams skip.
The old formula still works: keep three copies of your data, on two different kinds of media, with one copy offsite. What has changed is the assumption behind it. The original rule protected against fire, theft and failed drives. Ransomware is different. It goes looking for your copies and uses your own credentials to erase them.
So add a fourth condition: at least one copy must be impossible for a logged-in attacker to reach or delete. That means offline, immutable, or both. If your only offsite copy is a cloud folder synced with the same account your staff use every day, it is not a backup. It is a second copy of the problem.
A workable stack for a small business looks like this:
This is where most small businesses are weakest. The backup server is joined to the domain, an administrator account with the same password as everything else runs the jobs, and the console is reachable from every laptop. An attacker who compromises a single workstation can walk straight to it.
Create a dedicated backup account. It should not be a domain administrator, it should not be anyone's daily login, and it should not be reused on another system. Its only job is running and managing backups. If your software supports it, restrict the account so it can write backups but not delete them.
Put the backup host on its own network segment, or at least block inbound connections from staff workstations. Ransomware crews lean on remote desktop and file-sharing ports constantly, so the backup server should accept connections from as few places as possible. Turn on multi-factor authentication for the backup console and for any cloud storage holding copies. Then review who can log in. Retired accounts and shared logins are common holes.
A backup system is only as strong as the credentials that can reach it. If those credentials live on the same network as the phishing victim, they will eventually be found.
Ask two plain questions. How much data can we afford to lose? How long can we stay down? The answers decide your schedule. A business that invoices daily cannot accept losing a week of records. A small studio may care more about how quickly large project files come back.
In practice, a small business usually runs a full backup weekly with increments daily, or continuous backups to a local device with a nightly copy sent offsite. Keep more versions than feels necessary. Ransomware often encrypts quietly for days before it announces itself, so a single recent copy may already be contaminated. Thirty days of history is a reasonable starting point for most small teams.
A green checkmark means the job ran. It does not mean the data comes back. The only evidence that counts is a file you opened after restoring it. Run a drill on a schedule and treat it as real work.
If nobody but the person who built the system can restore from it, that is your biggest finding. Document the steps and have a colleague follow them cold.
Immutability means the data cannot be altered or deleted for a set period, even by an administrator. Many cloud backup providers offer it, often under names like object lock or retention windows. Rotated external drives and tapes give you the same protection physically, as long as they are disconnected between jobs.
The catch with offline copies is automation. If the drive sits plugged in "just in case", it is online. Script the backup, the dismount and the notification, then verify the drive actually leaves the system when the job finishes. A copy an attacker can reach is not a copy you can count on.
Recovery fails on details more often than on storage. Keep an offline record of encryption keys and recovery codes, because a password vault sitting on a locked network is useless. Store your backup provider's phone number somewhere you can reach without email. Keep notes on server configuration, licence keys and who to call. Before handing restored systems back to staff, confirm they can reach the internet for updates.
You do not need a fifty-page document. You need one page someone can follow at six in the morning under pressure. List who decides whether to restore or bring in outside help, who calls the provider, which systems come back first, and where the offline credentials are kept. Print it. Store a copy offsite.
Then do the boring part: review it every six months, after any major change to your network, and after every restore drill. A backup plan that gets tested, timed and adjusted is the closest thing a small business has to a guarantee that a bad morning stays a bad morning.
Photo: janeb13 / Pixabay