Most ransomware conversations start with the encryption event. That’s the wrong starting point. By the time files start locking, the attacker has usually already been inside the environment for days, and one of their first job, often before anything gets encrypted, is finding and disabling the backups. If that step succeeds, the ransom note isn’t really a negotiation. It’s the only option left.
Recent industry reporting backs this up. Sophos found that in the large majority of ransomware incidents, attackers actively attempted to compromise backup repositories before deploying the payload, and succeeded more often than not. Veeam’s own research tells a similar story, with the vast majority of victims reporting that their backup repositories were specifically targeted during the attack. This isn’t an edge case anymore, it’s standard operating procedure for ransomware groups.
The uncomfortable follow-up question for most IT teams is: would our backups survive that first move? Below are the gaps attackers look for first, roughly in the order they tend to check them.
Backups that live on the same network as production
If your backup repository is reachable from the same domain, the same admin credentials, and the same network segment as everything else, it isn’t really a separate copy of your data, it’s just another folder for the attacker to reach. Traditional backup targets (a Windows file share, a NAS mounted with domain credentials, a SAN volume presented to the same hosts) are exactly what ransomware operators go looking for once they’ve escalated privileges.
The fix isn’t complicated in principle: your backup storage needs to be logically or physically separated from production, with its own access path that doesn’t depend on the credentials an attacker is likely to have already stolen. As we’ve noted before, a single site-level event, fire, flood, or a ransomware attack, can take out local-only backups along with everything else, which is exactly why a second, genuinely isolated location matters as much as the backup itself.
No immutability on the backup files themselves
Even backups that sit in a separate location can be deleted or encrypted if the attacker gets hold of credentials with delete permissions on the backup target. This is where immutability closes the gap: a hardened, write-once repository means that once a backup lands, it genuinely cannot be altered or removed within its retention window, not by an attacker, and not even by a backup administrator with full access. Our Veeam hardened Linux repository architecture is built around exactly this principle: backups within the immutability window can’t be deleted or modified by anyone, including an admin whose credentials have been compromised.
If your current backup architecture can be deleted by someone (or something) with the right login, that’s a gap ransomware is specifically built to exploit.
One copy, one location
A single backup set, however well protected, is still a single point of failure. The long-standing 3-2-1 rule – three copies of your data, on two different media types, with one copy offsite – exists precisely because it assumes something will eventually go wrong with any one link in the chain. Modern ransomware-aware architectures extend that further, adding an immutable and/or air-gapped copy specifically because attackers now treat “find and destroy the backup” as a standard step, not an afterthought.
If you can trace every one of your backup copies back to the same storage array, the same cloud tenant, or the same set of credentials, you don’t have redundancy – you have one copy with extra steps.
Backup jobs that fail quietly
A backup job that’s been silently failing for three weeks is functionally the same as having no backup at all, except that nobody finds out until the moment they need it. Ransomware doesn’t cause this problem, but it exploits it ruthlessly, attackers who’ve been in an environment for a while have often had time to notice (or even engineer) gaps in job monitoring before they ever trigger the encryption stage.
Alerting on job failures is necessary but not sufficient. What actually matters is someone reviewing those alerts and confirming that recovery points are current, every time, not just when there’s a problem obvious enough to notice.
Restores that have never actually been tested
This is the gap that shows up at the worst possible moment. Plenty of organisations can point to backup jobs completing successfully every night and still discover, mid-incident, that a full restore takes far longer than the business can tolerate, or that a “successful” backup doesn’t restore cleanly. A completed backup job is not the same thing as a working recovery plan.
Recovery time and recovery point objectives (RTOs and RPOs) should be based on a restore you’ve run and timed, not a number lifted from a vendor spec sheet. If your last full restore test was a proof-of-concept demo two years ago, you don’t have a tested RTO, you have a guess.
Treating Microsoft 365 as “already backed up”
This one catches a surprising number of experienced IT teams. Microsoft is responsible for the uptime and infrastructure resilience of Exchange Online, SharePoint, OneDrive, and Teams, not for restoring data your organisation deleted, corrupted, or lost to a ransomware event. Native retention and recycle-bin features are compliance tools with finite windows, not a backup solution: if ransomware encrypts a mailbox, that encrypted version simply syncs back into Microsoft 365, rendering the retained history just as compromised as the original.
We go into this shared-responsibility model in more depth in our guide to what Microsoft 365 backup actually needs to cover across Exchange Online, SharePoint, OneDrive, and Teams. If SaaS data isn’t part of your independent backup strategy, it’s part of your ransomware exposure.
Backup windows and RPOs that leave too much on the table
Even a well-architected, immutable backup strategy has a gap built into it: the time between backups. If your RPO is 24 hours and an attack happens 23 hours into that window, you’re recovering a day’s worth of lost work on top of the incident itself. For some organisations that’s an acceptable trade-off. For others, particularly those running transactional systems, e-commerce, or anything with a low tolerance for data loss, a daily backup window is itself the gap that needs closing, through more frequent snapshots, continuous data protection, or both.
Relying on snapshots alone
Storage-level snapshots and Volume Shadow Copies are useful, fast, and exactly what ransomware operators are trained to delete first. They typically live on the same storage system as the data they’re protecting, which means an attacker with sufficient access can wipe them in seconds, often as one of the very first actions taken before the main encryption payload runs. Snapshots are a helpful operational tool for quick rollbacks, they are not a substitute for an independent, isolated backup copy.
Closing the gaps
None of the above is about buying a bigger backup product. It’s about architecture: where your backups live, who and what can reach them, whether they can be altered once written, and whether anyone has proven they can be restored under pressure. That’s the same reasoning behind building backup environments around hardened, immutable repositories and offsite cloud targets, the goal is to remove the assumption that “we have backups” automatically means “we can recover.”
Where Nexstor fits in
We don’t start from a product and work backwards, the right architecture depends on what you’re protecting, your recovery time expectations, and what’s already in your environment. But most of the gaps above map fairly directly onto the parts of our business built specifically to close them:
- Network-reachable, non-immutable backups (gaps 1 and 2): As a Veeam Platinum Partner, we build backup environments around Veeam’s hardened Linux repositories, which enforce immutability at the storage layer, backups can’t be altered or deleted within the retention window, even by an administrator whose credentials have been compromised. We also operate Veeam Cloud Connect as a provider, giving you an offsite, isolated target that sits outside your own domain and network path by design.
- Single copy, single location (gap 3): Nexstor.Cloud gives you a genuinely separate destination for your offsite or immutable copy, so the 3-2-1-1 principle isn’t just theoretical, it’s a real second environment with its own access controls.
- Untested restores and unclear recovery times (gaps 4 and 5): This is where NexProtect comes in, our managed service wrapping backup, disaster recovery, and (through our security partners) penetration testing together, so recovery gets tested and monitored on an ongoing basis rather than assumed to work.
- Microsoft 365 treated as already backed up (gap 6): Our Backup-as-a-Service for Microsoft 365 covers Exchange Online, SharePoint, OneDrive, and Teams independently of Microsoft’s native retention, closing the shared-responsibility gap directly.
- Backup windows too wide for the business (gap 7): Depending on the workload, this is a conversation about backup frequency and, where it’s warranted, DRaaS with tighter recovery point objectives for the systems that can’t tolerate a 24-hour gap.
What that looks like for your environment, isn’t something we’d want to prescribe generically here. That’s a conversation worth having directly, so we can look at your current architecture against these specific failure points before an incident forces the question.
