Attackers Go for Your Backups First. Most Companies Find Out Too Late.

The backup is the target now

For years, the standard backup conversation was about accidents. A drive fails. A server room floods. Someone deletes the wrong folder on a Friday afternoon. Backups were insurance against bad luck, and most plans were built for exactly that. Ransomware changed who the plan has to defend against. A modern attacker does not stumble into your environment and encrypt the first server they find. They spend time inside the network, learn where the valuable data lives, and identify the one thing that would let you refuse their demand: your ability to restore. Then they go after that first.

Veeam's 2025 Ransomware Trends and Proactive Strategies Report, based on a survey of 1,300 organizations, puts numbers on the shift. Sixty nine percent of organizations said they had experienced at least one ransomware attack in the past year. In 89 percent of those cases, the attackers targeted the backup repository. That targeting was deliberate, not collateral damage. The backup is attacked because it is the exit. Remove the exit, and the victim has two options left: rebuild from nothing, or pay.

The recovery outcomes in the same research show how well that strategy works. Only 10 percent of attacked organizations recovered more than 90 percent of their data, while 57 percent recovered less than 50 percent. Read that second figure slowly. For most victims, the event did not end with a restore and a bad week. It ended with more than half of the affected data gone, rebuilt by hand, or abandoned. And paying did not reliably close the gap either. Thirty six percent of affected organizations refused to pay at all, and among those that did pay, 17 percent reported that they still could not retrieve their data.

Why a green backup job is not a recovery plan

Ask most IT leaders whether their backups are in good shape and they will point to the job history: green check marks, night after night. That history proves a copy was written. It says nothing about whether the copy would survive an attacker, or whether anyone could actually restore from it under pressure. Three gaps account for most of the distance between a running backup job and a working recovery.

The same accounts can delete production and backups

In many environments, the backup repository sits inside the same identity system, and is reachable with the same privileged accounts, as the production servers it protects. That arrangement is convenient right up until an attacker holds one of those accounts. At that point, offsite stops meaning safe. A copy stored in another building, or another city, that the compromised account can still reach and delete is protected from weather. It is not protected from the person now running your network. Veeam makes the test blunt: list every account, including service accounts and the identity that runs the backup software itself, that can delete both the production data and its backup copy. If that list is not empty, an attacker only has to become one of those names.

Backups that can be edited can be deleted

The direct fix for that exposure is immutability: a backup copy that cannot be changed or deleted by anyone, including your own administrators, until its retention period expires. It sounds like a standard feature, and the adoption numbers say otherwise. In Veeam's research, only 32 percent of organizations were using repositories configured as immutable, even as 89 percent reported their backups being targeted. Computer Weekly's reporting on the same research adds the consequence: in about a third of targeted cases, the repositories were successfully modified or deleted. A backup an attacker can reach and alter is not a recovery point. It is another file to encrypt.

A restore nobody has run is a guess

The third gap is the quietest. Recovery is usually the least tested part of the whole system, because testing takes time, spare capacity, and a willingness to discover bad news on a calm Tuesday. So the first full restore often happens during the incident itself, with leadership waiting, customers calling, and a clock running. Veeam found that organizations consistently overrate their readiness before an attack: confidence in being prepared dropped by about 20 points on average after organizations had actually been through one. The restore that has never been run has unknown timing, unknown gaps, and unknown dependencies. Nobody learns what their recovery time really is until the day they can least afford the lesson.

What to fix, in order

None of this requires a rip and replace project. It requires fixing the gaps in the order an attacker would exploit them.

1. 1Inventory what you actually back up: every database, file store, and cloud workload, and name the business process each one supports
2. 2List every account that can delete both production data and its backups, then remove that overlap or split the duties
3. 3Put at least one copy in an immutable repository that no admin account can alter or delete before retention expires
4. 4Keep one copy isolated from your normal network and identity system, so a compromise of production cannot reach it
5. 5Run a timed restore of your most critical system into a clean environment, and record how long it really takes
6. 6Repeat the restore test on a set schedule, and fix what each test finds while the stakes are low

Two definitions make the list concrete. Your recovery point is how much data you can afford to lose, stated in time: an hour of orders, a day of entries. Your recovery time is how long the business can operate without the system before the damage becomes unacceptable. Backups should be scheduled, stored, and tested against those two numbers, not against whatever default the software shipped with. If leadership has never stated the numbers, that conversation is the real first step, because every technical choice after it depends on the answers.

Notice what the sequence does not start with: shopping. Storage and backup platforms matter, and an immutable, isolated copy usually does require the right tooling. But tooling bought before the account overlap is fixed, and before anyone knows the recovery numbers, tends to reproduce the old design on newer hardware. The architecture decisions come first. The purchase supports them.

What this means if you run a company in Oklahoma

Oklahoma companies run the same risk profile as everyone else with a fraction of the bench. In a lean IT shop, the person who administers the servers also administers the backups, often with one shared set of powerful accounts, because there is nobody else to split the duties with. That makes the account overlap problem structural, not careless, and it makes an outside review valuable precisely because the fix is about design, not effort. The questions are also arriving from outside the IT department now. Cyber insurers ask about immutable backups and tested restores at renewal. Auditors and larger customers ask the same questions in security reviews. A company that can answer with a dated restore test and a repository nobody can delete answers from strength. A company that answers with a screenshot of green backup jobs is hoping the follow up questions never come. Handled now, this is a short, planned project with a clear order of work. Handled during an incident, the same work becomes the reason the recovery stalls.

At Oklahoma Data Partners, backup and recovery design sits inside the database administration and data consulting work we do every week: reviewing backup architecture, separating recovery from production accounts, setting up immutable copies, and running restore tests that prove the plan before it is needed. If you have never seen your most important system restored from its own backups, book a consultation and we will tell you plainly whether your recovery would hold up, and what to fix first.