Ransomware backups fail in one common way. Yes, ransomware can encrypt your backups: if a backup is permanently connected to the computer or server it protects, the ransomware can reach it too, and you are left with nothing to restore from.
It is the most common way a backup fails when it matters, and it is easy to check. This post explains why it happens and gives you five checks to make this week.
A story worth learning from
A consultant told The Register’s PWNED column (8 October 2026) about a small construction company whose owner turned down a security proposal as too expensive. Three weeks later, ransomware hit. The company’s key data sat on an unpatched Windows server, and its only backup was an external drive plugged into that same server.
The ransomware encrypted both. According to the consultant, the business closed within months. The article doesn’t say where the company was based, and it is one account rather than a statistic, but the mechanism is entirely ordinary.
Nothing about it was exotic. A server that hadn’t been patched, and a backup that was always attached, are two familiar weaknesses.
Why attached backups are not enough
Ransomware doesn’t only encrypt the files on the machine it lands on. It looks for anything it can reach: shared folders, mapped drives, attached disks, and cloud sync folders.
The NCSC’s Small Business Guide says backups shouldn’t be permanently connected to the device that holds the original data, because malware can move across to attached storage. It also describes keeping at least one backup offline, or otherwise disconnected, so one incident can’t hit every copy (NCSC, Backing up your data; NCSC, Offline backups in an online world).
Some attackers go further. The NCSC’s malware guidance notes that they have destroyed copied files or disrupted recovery before a ransomware attack, which is why it recommends multi-factor authentication on backup accounts.
Backups can fail in three quiet ways. They can be reachable by the attacker, so they are encrypted or deleted. They can be incomplete, because the thing that mattered was never included. Or they can be untested, so nobody knows whether they work until the day they are needed.
The five checks below cover all three. None needs special software, and you can do most of them in an afternoon.
Check one: do you have a copy that isn’t always connected?
List every place your business data is copied to. For each, ask whether it is reachable from your day-to-day network and accounts all the time.
You need at least one copy that is not. That might be a rotated disk kept off site, or a cloud backup with separate credentials and no always-on connection to your main systems. The point is that a single mistake or attack can’t reach every copy.
Check two: is your cloud data actually backed up?
Many businesses assume Microsoft 365 backs up their email and files. It keeps your service running, but that isn’t the same as a separate, restorable copy of your data. We explain the gap in our Microsoft 365 backup myth post.
If your files, email and Teams chats live in the cloud, ask who is backing them up, where those copies live, and how you’d get something back.
Check three: who can get into the backup account?
A backup is only as safe as the account that manages it. If an attacker steals an administrator’s login, they can delete the backups from inside.
Turn on multi-factor authentication for every backup and admin account, and keep the second factor off the device you use to administer the backups. Use separate admin accounts for backup work, not the one you use for email.
Check four: have you ever restored from it?
A backup that has never been tested is a hope. Pick a handful of files and restore them to a different location. Then try a bigger test: a whole folder, or a mailbox.
Note how long it takes. Restoring a few files is quick. Restoring a whole server can take much longer than people expect, and you want to find that out before you need it.
Check five: is the thing being backed up patched?
In the story above, the unpatched server was how the attack began. A backup helps you recover, but it doesn’t stop the same hole being used again.
Make sure servers and laptops get updates on a schedule, and that someone is responsible for confirming it. If you still run an on-premises server, ask whether it needs to be there at all.
A simple test of your own backups
Ask yourself four questions. Could an attacker who controls a laptop on your network delete every copy? Does at least one copy sit outside your normal accounts? Has someone restored from it in the last few months? Do you know how long a full restore would take?
If any answer is no or I don’t know, that is where to start. A plain list of the answers is also exactly what an insurer or a customer’s security questionnaire may ask you for.
Where we come in
Backups and disaster recovery support are part of the managed IT support we provide, alongside monitoring, patching and cyber security. If you’d like to know whether your backups would survive a ransomware attack, speak to Matt. If you’re not ready to talk, our disaster recovery planning post is a good place to start building your own plan.
Frequently asked questions
Can ransomware encrypt backups?
Yes. Ransomware can reach any backup that is permanently connected to the infected computer or network, including attached drives and some cloud sync folders. Keeping at least one copy disconnected from your live systems protects it.
What is an offline backup?
An offline backup is a copy of your data that is not connected to your live systems when it isn’t being used. The NCSC advises keeping at least one, so a single incident can’t affect every copy.
Is Microsoft 365 a backup?
Not on its own. Microsoft keeps the service running, but that is different from holding a separate copy of your data that you can restore from. Check who backs up your cloud data and how you would get it back.
How often should I test my backups?
Test a restore regularly, and after any change to your systems. Start with a few files, then try a larger restore, so you know it works and how long it takes.
