Your Backup Will Not Survive a Ransomware Attack

Most businesses we assess are confident about one thing and wrong about it. They take backups, the jobs report success every morning, and they believe that means they could recover from a ransomware attack.

They usually could not, and the reason is not that the backups are bad. It is that the attack is not shaped the way they think it is.

The attack does not start with encryption

The mental model most people carry is that ransomware arrives, files encrypt, and you restore from last night's copy. That picture is roughly a decade out of date.

A modern intrusion starts quietly. Someone clicks something, or a credential bought from a broker works, and an attacker gets a foothold. Then they wait. They map the network, escalate privileges, and look for the things that would let you recover without paying. The backup server is high on that list, because destroying it is what turns an incident into a negotiation.

So the order of events is: get in, stay hidden for weeks, find the backups, destroy or encrypt the backups, then encrypt production. By the time anyone notices anything is wrong, the thing that was supposed to save the business has already gone.

This is why a backup your domain administrator account can delete is not a recovery plan. Once an attacker holds that account, and holding that account is the point of the weeks they spent hidden, they hold your backups too.

What immutability actually means

An immutable backup is a copy that cannot be changed or deleted until a set retention period has passed, and the restriction is enforced by the storage layer rather than by file permissions.

The distinction matters more than it sounds. Permissions are a rule that an administrator can change. Immutability is a property of the storage that an administrator cannot override, which means stealing the administrator account is no longer enough.

Two implementations are common:

• Object lock on S3-compatible storage. The object cannot be overwritten or deleted before its retention date expires, regardless of the credentials presented.
• A hardened Linux repository. The backup software writes through a service account with no interactive login, and the immutability flag is set at the filesystem level on a machine that is not joined to your domain.

The second point there is the one most often skipped. A backup repository joined to the same Active Directory as everything else shares the fate of that directory. Separating the credentials is free, and it removes the single most common path to a total loss.

3-2-1, and the two digits that were added for a reason

The old rule was 3-2-1: three copies of your data, on two different media, with one offsite. It is a good rule and it was written before ransomware targeted backups.

The current version is 3-2-1-1-0:

• 3 copies of the data
• 2 different media types
• 1 copy offsite
• 1 copy immutable or physically offline
• 0 errors on a verified restore test

Nearly every plan we review satisfies the first three and neither of the last two. Those are precisely the two that were added in response to how attacks actually work now.

The quieter failure: nobody has ever restored anything

Set ransomware aside for a moment, because there is a more mundane way this goes wrong.

Backups run. The job reports success. Nobody ever restores one. Then a server dies, or somebody deletes the wrong thing, and the first real restore attempt in the company's history happens on the worst possible day, under time pressure, by someone who has not done it before.

That is when people discover the database was backed up but the encryption key was not, or the restore takes eleven hours over a connection nobody sized for it, or the retention was thirty days and the corruption started forty days ago.

A successful backup job is a claim. A timed, documented restore into an isolated environment is evidence. They are not the same thing, and only one of them is worth anything at 3 AM.

Start with two numbers, not with a product

Almost every conversation about backup starts with a product name. It is the wrong end of the problem. Two numbers should come first, and they belong to the business rather than to IT:

• RTO, recovery time objective. How long can you be down before the damage is unacceptable? Not ideal: unacceptable.
• RPO, recovery point objective. How much data can you afford to lose, measured in time? If you restore to a point four hours ago, can the business reconstruct those four hours?

Once those are agreed, the technical design follows from them and, more usefully, so does the cost. A four-hour RTO with a fifteen-minute RPO is a genuinely different system from an overnight backup, and it costs accordingly. Sometimes the overnight backup is the right answer, and you can only know that once somebody has said out loud what downtime actually costs.

This is also the conversation that settles product arguments. Veeam, the native tooling in Azure and AWS, and several open-source options all do good work. Which one is right depends on what you are protecting, whether it lives on-premise or in cloud or both, those two numbers, and what your team can realistically operate at two in the morning. Choosing the product first and deriving the requirements afterwards is how businesses end up paying for capability they never use, alongside a gap they never noticed.

A short list worth going through this week

None of this requires a project to begin. Six questions, and the answers are usually available in an afternoon:

1. What is actually backed up, and just as importantly, what is not? Laptops, SaaS data and the Microsoft 365 tenant are the usual blind spots.
2. Can the account that administers your network also delete the backups? If yes, that is the finding.
3. Is any copy immutable, or genuinely offline?
4. When was the last restore test, and how long did it take?
5. What are your RTO and RPO, and who in the business agreed them?
6. If your primary site were unavailable tomorrow morning, who decides what happens, and does anyone outside IT know the plan exists?

If question two makes you pause, deal with that one first. It is the cheapest to fix and the most expensive to ignore.

We run this as a recovery assessment: what is protected, what is not, where the copies sit relative to an attacker, and how long a real restore would take. You get the findings in plain language with costed options, whether or not you do the work with us. We are independent, so the recommendation is not tied to any one product.