The move from tape to disk-based backups was one of the most significant shifts in data protection history. Disk backup security, as it turns out, wasn’t something anyone thought about during that transition. We were too busy celebrating the end of shoe-shining tape drives, failed restores, and the man in a van who took our tapes offsite. We solved a lot of problems. We also created a new one that ransomware attackers now exploit every single day.

This blog post summarizes the main points of my latest podcast episode. If you’d like, you can listen to it or watch it at https://www.backupwrapup.com/

Why We Abandoned Tape in the First Place

To understand the disk backup security problem, you need to understand why we moved to disk. Tape drives, particularly linear tape like LTO, have a fundamental requirement: they need data fed to them fast. A modern LTO-10 drive wants a gigabyte per second. Even older drives needed 15-30 megabytes per second minimum.

The problem? Most backups are incremental. You’re scanning file systems looking for changed files, finding maybe a megabyte every minute. The tape drive can’t write that slowly—the signal-to-noise ratio requires speed. So the tape does this thing called shoe-shining, going back and forth trying to keep up with the trickle of data. It wears out the tape. It wears out the drive. It makes everything unreliable.

IBM was the first to put disk in front of tape with what became Tivoli Storage Manager (now Spectrum Protect). We all thought they were crazy because disk was expensive. Then around 1999, deduplication changed everything. Companies like Avamar (originally called Undoo with two O’s) and Data Domain figured out how to find duplicate blocks across backup sets and just store pointers. Combine that with cheaper SATA drives replacing expensive fiber channel storage, and suddenly disk backup was affordable.

The Benefits Were Real—And Significant

I don’t want to minimize what disk-based backups gave us. The benefits were substantial:

Backup verification became practical. Products like Veeam introduced features where you could spin up a VM directly from your backups to test them without actually doing a restore. You could run automated recovery testing in isolated environments. With tape, testing meant loading tapes and hoping for the best.

Replication eliminated manual offsite copies. Deduplication reduced daily backup sizes to less than half a percent of total environment size. That meant we could replicate backups over WAN links. Onsite backup, offsite backup, one hundred percent automated. No more handing tapes to Iron Mountain.

Virtual synthetics made restores faster. The old tape method required monthly fulls, weekly differentials, and daily incrementals. A typical restore meant loading the monthly full, the latest weekly, and then six daily incrementals. If files changed multiple times, you were restoring the same data repeatedly. With deduplicated disk storage, you could create virtual fulls using pointers—no data movement required. Every backup looked like a full backup to the software.

These weren’t incremental improvements. Backups became dramatically more reliable than they had ever been.

The Disk Backup Security Problem Nobody Anticipated

Here’s what nobody thought about during this revolution: disk backup security was never part of the architecture.

When your backups lived on tape, they were inherently protected by physics. A tape sitting in a vault can’t be deleted remotely. You’d need physical access. Even tapes in a library required specific commands through specific interfaces to erase.

Disk backups? They sit in a file system. Maybe E:\backups on Windows. Maybe /backups on Linux. And if a threat actor gains access to a system with privileges on that path, they can delete everything with one command.

rm -r *, del /r *.*. Years of backup data, gone in seconds.

This is the disk backup security gap that ransomware attackers learned to exploit. They don’t go after your production data first. They go after your backups. Because they know that if you have no backups, you have no choice but to pay.

Disk Backup Security Is Now the Number One Target

I remember working with Veeam years ago when they first acknowledged this threat publicly. Their motto was “it just works,” and having to tell customers “it just works, but also here’s this threat you need to address” was uncomfortable. To their credit, they responded with countermeasures. Every major backup vendor has had to do the same.

The statistics are clear: backup systems are the first target after initial access. Threat actors specifically look for backup software, identify where backups are stored, and try to eliminate them before doing anything else. If they can delete your backups and your shadow copies and disable Windows Backup, you’re stuck.

Products like Veeam that run on Windows were particularly targeted because Windows environments were common attack targets anyway. But this isn’t a Veeam problem—it’s an architecture problem that affects any disk-based backup that stores data in accessible file systems.

Fixing the Disk Backup Security Gap

The solution comes down to a simple principle: if you can delete the backups, they can delete the backups. You need to make deletion impossible.

Immutable storage is non-negotiable. This is the standard now. Your backup storage must be truly immutable—data cannot be modified or deleted regardless of who’s asking, even administrators, even the backup software itself. Object storage with retention locks, hardened Linux repositories, purpose-built backup appliances with immutability baked in. Whatever approach you take, the test is simple: can anyone delete these backups before the retention period expires? If yes, it’s not immutable.

Get backups out of user space. If you can navigate to your backup folder in Windows Explorer or with a basic ls command, that’s a problem. Backups shouldn’t live in paths that regular system access can reach.

Consider obfuscation. Rename your backup directories to something that doesn’t scream “delete me.” Name your backup processes something other than the default. This isn’t security by itself—it’s a speed bump. But speed bumps slow attackers down, and slower attackers are more likely to get caught.

The bear analogy applies. You don’t have to outrun every threat actor. You just have to be a less appealing target than the next organization. Immutability, restricted access, and obfuscation together make you harder to compromise than someone with E:\BACKUPS sitting wide open.

Disk Backup Security Requires Acknowledging the Problem First

The first step in solving any problem is admitting it exists. The disk backup revolution made our lives better in countless ways. It also created a security vulnerability that we’ve been addressing ever since. The tools exist. The techniques are well-documented. Immutable storage products are available from every major vendor.

What remains is implementation. If your backups aren’t on truly immutable storage today, you’re vulnerable. The threat actors know about disk backup security gaps. They’re counting on you not knowing—or not acting on what you know.

Don’t give them that advantage.

Written by W. Curtis Preston (@wcpreston), four-time O'Reilly author, and host of The Backup Wrap-up podcast. I am now the Technology Evangelist at S2|DATA, which helps companies manage their legacy data

The post Disk Backup Security: The Vulnerability We Created appeared first on Backup Central.