A story reported by The Register this month is a blunt lesson in ransomware backup mistakes small business owners can still avoid. A company reportedly declined to pay for security help, ran an old unpatched system, and kept its only backup on a drive plugged into the same server. When ransomware hit, both were encrypted. According to the report, the company went bust months later.
The details we have are limited, and the source text is partial. But the pattern it describes is common enough to be worth unpacking.
How one unpatched server and one attached drive sank a business
According to the report, the business was running an old, unpatched system that held its data. There was a backup, but it consisted of a single external drive connected to that same server. Security consultant Hatter, who was approached after the attack, described the situation this way: "Their entire backup is this external drive, which, of course, is now encrypted."
The consequences were immediate and operational. In Hatter's words, "literally, they can't pay their employees. They don't know who owes them money." That is the real cost of ransomware for a small firm: not an abstract data loss, but payroll, receivables and day-to-day records vanishing at once.
Hatter could not help the company, and he never found out whether it paid the ransom. The article's headline says the business failed months later. The takeaway is that two ordinary gaps, a missing patch and a badly placed backup, were enough to turn an incident into an existential threat.
Why connected backups get encrypted along with everything else
Many small businesses treat a backup as a box to tick: buy a drive, plug it in, forget about it. The problem is that ransomware does not care which files are "the originals." It encrypts anything it can reach, including attached drives and mapped network shares.
An external drive that stays connected to the server looks like a separate device, but to the operating system it is just another storage location. If the malware runs with enough permissions to encrypt the server's data, it can usually encrypt the drive too. That is exactly what happened here.
A useful way to think about it: a backup only counts if an attacker who controls your main server cannot change or delete it. If the backup is always online and writable from that server, it fails that test.
Two other weak spots are worth naming:
- Never testing restores. A backup you have not restored from is an assumption, not a plan.
- One copy only. A single drive protects against hardware failure at best. It is a single point of failure against almost everything else.
Patching and access hygiene that would have blunted the attack
The report does not say exactly how attackers got in, only that the system was old and unpatched. Unpatched software is a well-worn route. The Gunra ransomware campaign against critical infrastructure, for example, involved attackers exploiting known Fortinet vulnerabilities, the kind of flaws that fixes already exist for.
For a small business without a dedicated IT team, a few habits go a long way:
- Keep an inventory. List every server, laptop, router and firewall. You cannot patch what you have forgotten exists.
- Turn on automatic updates wherever possible, and schedule a regular check for devices that cannot update themselves.
- Retire or isolate unsupported systems. If software no longer receives updates and cannot be replaced yet, keep it off the internet and away from your main data.
- Limit privileges. Everyday accounts should not have administrator rights, and remote access should require multi-factor authentication.
None of this requires an expensive tool. It requires someone being responsible for it.
Building a backup setup that survives ransomware
A resilient setup does not need to be complicated. A widely used guideline is the 3-2-1 approach: three copies of your data, on two different types of storage, with one copy kept off-site. To make it ransomware-resistant, add these points:
- Keep at least one copy disconnected or immutable. That could be a drive that is only connected during the backup window and then unplugged, or a cloud or storage service that supports versioning and cannot be overwritten by your server's credentials.
- Separate the credentials. The account that writes backups should not be the same one an attacker would get by compromising your server.
- Keep version history. Syncing a folder to the cloud is not the same as backing it up, because a sync service may faithfully copy encrypted files.
- Test restores on a schedule. Pick a few critical files, such as payroll and customer records, and restore them to see how long it takes.
- Write down the recovery order. Know what you need first to pay staff and invoice customers.
What This Means For You
If you run or work for a small business, this story is less about one company's choices and more about a checklist you can run this week. Ask yourself: where is my backup, and is it connected to my main system right now? When did I last restore from it? Which of my devices are no longer getting updates?
It also helps to be honest about cost. Paid security help can feel optional until the day it is not. Even a one-off review to identify unpatched systems and fix your backup layout is far cheaper than losing payroll and customer records. Ransomware's wider fallout is real: the vendor ransomware breach that exposed 442K patients' data shows how an attack on one organization can ripple out to many people.
Actionable takeaways
- Audit your backups today: confirm where they live and whether an infected server could reach them.
- Keep at least one offline or immutable copy, plus one off-site.
- Patch systems promptly and isolate anything that cannot be updated.
- Use multi-factor authentication and remove unnecessary admin rights.
- Test a restore this month, and repeat on a schedule.
The ransomware backup mistakes small business owners make are rarely exotic. They are an old server, a single drive and an assumption that it will be fine. Fixing them takes an afternoon, and it could decide whether your business is still operating after an attack.
