How to Protect Your Disaster Recovery Platform Against Cyber Attacks 

Ransomware actors don’t hang around anymore. They break in, elevate to domain admin, and start encrypting everything they can find. Just ask Marks & Spencer, whose online shop was down for months after a devastating ransomware attack earlier this year. 

If you think your disaster recovery platform is a silver bullet against these attacks, you might need to reconsider. Because while your backups might be your last line of defence, they’re only as good as the security wrapped around them. 

Cyber Security Analyst, Alex Wells-Linden, recently sat down with Consultant Matt Dyson to discuss the harsh realities of ransomware recovery and why “just restore from backup” isn’t the golden button many businesses think it is. Want to watch their full discussion? Check out the video below. Otherwise, read on to find out more. 

We’re moving past the days when ransomware actors would lurk in your network for six months, learning every nook and cranny. Today’s attacks are more “smash and grab” operations: they get in, get elevated privileges, and start encrypting within days or weeks. 

According to Sophos’s latest State of Ransomware report, exploited vulnerabilities are still the most common technical root cause of ransomware attacks, accounting for 32% of incidents. 

That’s nearly a third of ransomware attacks that start by targeting weaknesses in external-facing infrastructure and software defenses (think misconfigured firewalls or unpatched vulnerabilities). 

The remaining attacks? They’re predominantly identity-driven through phishing, password stuffing, and compromised credentials. 

Why the shift to speed? Modern endpoint detection and response (EDR) tools have become remarkably good at spotting unusual behaviour. The longer attackers hang around, the more likely they are to trigger an alert. So they’ve adapted; moving fast and hitting hard before security teams can respond. 

Many organisations have their backup servers sitting on the same network as their production systems. Yes, it makes for quick restores when someone accidentally deletes a file. But when ransomware hits? Those backups become just another encrypted victim. 

The backup platform itself can be a target. Veeam, one of the most popular backup solutions, has had its share of vulnerabilities over the years. In 2024, attackers exploited critical vulnerabilities in Veeam Backup & Replication to deploy ransomware. It’s a punchy reminder that your backup infrastructure needs the same security rigour as your production systems. 

Your backups really need to be: 

• Immutable: Unable to be modified or deleted, even by admins 
• Air-gapped: Isolated from your production network 
• Geographically dispersed: Not just in a different datacentre, but properly separated 

Why immutability is non-negotiable 

Let’s be clear about what immutability actually means: once a backup is written, it can’t be changed or deleted by anyone (not even domain admins) until a predetermined retention period expires. This isn’t just “read-only” or “restricted access.”, it’s mathematically enforced impossibility. 

Why does this matter? Imagine two scenarios: 

First, a ransomware attacker manages to gain domain admin credentials (not an uncommon occurrence). Without immutability, those credentials can delete every backup you’ve got. With immutability, those backups stay untouchable. The attackers can rage all they want, but those files aren’t going anywhere. 

Second, the insider threat. Whether it’s a disgruntled employee or an admin account that’s been compromised, immutable backups protect against both malicious and accidental deletion. Nobody can “accidentally” delete last month’s backups during a routine cleanup. 

Modern platforms implement this differently. Veeam uses Linux hardened repositories, Azure Backup has immutable vaults, and some solutions use WORM (Write Once, Read Many) storage. But the principle stays the same: if your backups can be deleted with the right credentials, they’re not truly protected. 

When Marks & Spencer got hit with ransomware, their online shop was down for months. 

Why does recovery take so long? It’s not just about clicking “restore” on your last backup. If you find yourself in a similar situation, you’re faced with an impossible choice: 

Option 1: Go back a few days 

You’ll probably restore to a compromised state. The attackers were likely already in your network, with persistence mechanisms in place. Now you need to restore each system individually into an isolated network, run incident response on every machine, root out the nasties, and hope you’ve found everything. 

Option 2: Go back a few months 

You’re probably safe from the initial compromise. But you’ve just lost months of data. Every transaction, customer update, and business change—gone. It won’t be easy explaining that to the board. 

And while you’re making this decision, the clock’s ticking. You’ve got: 

• Opportunity costs from being offline 
• Reputational damage that might last years 
• ICO fines for data breaches (because the attackers probably exfiltrated data too) 
• Potential ransom payments (which may or may not be effective) 

“We’ve got backups” isn’t a disaster recovery plan. Neither is “we’ve got ASR configured.” If you’re not testing your recovery procedures at least annually, you’re flying blind. 

It’s not uncommon for organisations to fail over to their DR site only to discover they’ve forgotten to replicate firewall rules. Or they’ve backed up the OS drive but not the data drives with the actual databases. 

So you’ll need a comprehensive testing plan, and that means: 

The full failover test 

Can you actually fail over to your DR site and have everything work? Not just the technical bits, but the whole business process. Who makes the decision? Who has the passwords? Who knows what to do? 

The backup restoration test 

Those backups you’ve been religiously taking—do they actually work? Can you restore them quickly enough to meet your RTO? Too many “successful” backup jobs turn out to be backing up corrupt or incomplete data. 

The “presumed breach” scenario 

This is the nightmare scenario that’s becoming increasingly common. You’re not just restoring from backup; you’re restoring while assuming the backups themselves might be compromised. How do you clean each system as you bring it back? What’s your process for ensuring you’re not just re-importing the ransomware? 

Getting buy-in for these tests can be challenging. Here’s a question that usually works: “What’s more likely: our head office burning down, or us getting ransomware?” In 2025, the answer is pretty clear. Your cyber insurance premiums probably cost more than your building insurance for a reason. 

If your disaster recovery platform is your last line of defence, it needs fortress-level protection. Here’s what that looks like in practice: 

Network segregation is non-negotiable 

Your backup infrastructure should be on a completely separate network from production. Yes, it makes management slightly more complex. But when ransomware tears through your production network, those extra firewall rules might be the only thing standing between you and complete disaster. 

Identity and access management for DR systems 

That “break glass” admin account for your DR platform? If the password is “written down somewhere safe,” you’re doing it wrong. Your DR platform needs the same super-strong identity management as everything else, but with even stricter controls. You might consider: 

• Separate tenant or identity provider for DR systems 
• Privileged access management (PAM) solutions 
• Regular access reviews (who still has those emergency credentials?) 

Beyond annual pen testing 

Annual penetration testing gives you a compliance tick box. But between those annual tests, a single misconfigured firewall rule could expose everything. Modern approaches like breach and attack simulation (what Gartner now calls “automated exposure validation“) continuously test your environment, finding and fixing vulnerabilities before the bad actors do. It could be well worth looking into. 

Whether you’re using Veeam, Datto, Azure Backup, or any other platform, the core security principles are the same. You need network isolation, immutable storage, strong access controls, and regular testing. 

That said, each platform does offer specific features that can strengthen your ransomware defences. 

Veeam Backup & Replication: Veeam’s Linux hardened repository feature is particularly valuable. It creates an immutable backup storage that even root users can’t delete during the retention period. Their insider protection features help prevent malicious deletion by rogue admins. But remember those vulnerabilities from 2024? Keeping Veeam itself patched and updated is super important. The platform you’re using to protect against ransomware can’t become an attack vector itself. 

Datto SIRIS/ALTO: Being a SaaS-based solution, Datto handles much of the infrastructure security for you, which is one less thing to worry about. Their screenshot verification and built-in ransomware detection can spot encrypted files before you restore them. The trade-off is that you’re trusting a third party with your last line of defence, so make sure you understand their security posture too. 

Azure Backup: Microsoft’s native solution integrates beautifully with Azure RBAC, making access control straightforward if you’re already in the Azure ecosystem. The soft delete feature means even if someone deletes your backups, they’re recoverable for up to 14 days. Plus, immutable vaults prevent anyone (including subscription owners) from deleting backups before their intended expiry. 

Azure users: make sure you know the difference between Azure Backup and Azure Site Recovery. They’re complementary, not competing solutions: 

• Azure Backup gives you those point-in-time restores for when things go wrong. 
• Azure Site Recovery (ASR) provides the rapid failover capability for true disaster scenarios. 

Commvault: Their threat scan feature actively looks for anomalies in backup data, whilst honeypot capabilities can detect ransomware behaviour early. It’s comprehensive, but that complexity means more to configure and potentially misconfigure. 

The platform matters less than how you configure it. A properly secured Veeam deployment beats a poorly configured Commvault setup every time. 

When we talk about disaster recovery, we often focus on the technical bits. But modern business continuity looks different than it did even five years ago. With remote working now standard, “head office burns down” might just mean “everyone works from home for a bit.” 

Cloud platforms like Azure have fundamentally changed the game. Need to scale from 50 to 500 remote workers? With Azure Virtual Desktop, that’s an hour’s work, not a procurement nightmare. Your disaster recovery platform should let you maintain business ops however and wherever your people need to work. 

But you need to balance security with recovery speed. Consider your RPO (Recovery Point Objective: how much data you can afford to lose) and RTO (Recovery Time Objective: how long you can afford to be down). These targets you’ve committed to are meaningless if you can’t achieve them securely. It’s better to take 48 hours to recover properly than 4 hours to restore a compromised environment. 

And here’s something else to think about: having cyber insurance could make you a more attractive target. Attackers do their homework. They know who’s insured and therefore more likely to pay. Not saying you shouldn’t have it (you absolutely should), just don’t let insurance become a substitute for proper security. 

Your disaster recovery platform probably is your last line of defence. But that doesn’t make it a silver bullet. As the Marks & Spencer incident and countless other ransomware attacks have shown, having backups doesn’t mean you can recover quickly (or at all). 

If you’re a business of any significant size, ransomware isn’t a matter of “if” but “when.” The attackers only need to get lucky once. You need to get it right every single time. 

So yes, invest in your disaster recovery platform. Configure ASR. Take those backups. But more importantly: 

• Protect them like production systems (because to ransomware, they are) 
• Test them regularly (not just the technology, but the entire process) 
• Assume a breach will happen (because that’s increasingly the reality) 

At Synextra, we specialise in helping businesses build and secure their Azure disaster recovery strategies. We know that in today’s world, ‘good enough’ isn’t good enough. Your last line of defence needs to be your strongest. 

Want an expert overview of your disaster recovery posture? Get in touch today.