Having backups doesn’t mean you can recover from ransomware. Attackers hit backup infrastructure first, often long before encryption starts, and they almost always succeed. According to Veeam’s 2025 Ransomware Trends Report, 89% of attacks target backup repositories. Only 32% of organizations have immutable backup copies in place, and 57% recover less than half of their data. This guide covers the backup architectures that actually survive a modern ransomware attack, and it walks through what an effective recovery process looks like when everything else has failed.
What is server ransomware recovery?
Server ransomware recovery is the process of restoring encrypted systems, pulling data back from backup, and returning operations to normal after an attack. It sounds straightforward, but it isn’t. Unlike recovering from a hardware failure or accidental deletion, ransomware recovery starts with an active adversary still inside your environment. By the time encryption begins, the attacker has often spent days mapping infrastructure, stealing credentials, disabling backup agents, and setting up persistence. That changes everything. Isolation, backup selection, and recovery environment design all need to assume the attacker is still watching.
What ransomware does to your infra before you notice?
Encryption is the final stage, not the first. Attackers usually get in through phishing, exposed RDP services, compromised VPN credentials, or some other externally reachable entry point. From there, they move laterally, escalate privileges (often all the way to domain administrator), and quietly map the environment. According to Mandiant’s M-Trends research, the median time between initial compromise and encryption is about five days. So that backup you created three days before encryption? It might already be compromised. Once the attacker has domain admin, the destructive phase can unfold in minutes: backup catalogs get deleted, backup services get stopped, and recovery infrastructure is deliberately targeted before encryption even starts.
Most ransomware groups also exfiltrate data before they trigger encryption. Paying the ransom doesn’t help with that. The data is already out.
The impact goes well beyond IT. When Ascension Health was hit in May 2024, clinical staff across 140 hospitals lost access to systems used for medication management and care coordination. Many of them reverted to paper-based workflows, and critical procedures were delayed for days.
A year later, Asahi Group Holdings suffered a ransomware attack that halted production at six breweries and several soft-drink facilities across Japan. The incident showed how an IT compromise can quickly become an operational technology problem, and how a beer shortage is, in fact, a business continuity event.
For most organizations, ransomware becomes a business continuity event within hours. Not an IT problem. A business problem.
Why backups fail?
Simply having backups doesn’t guarantee you’ll be able to restore from them. Modern ransomware operators understand backup infrastructure just as well as the administrators defending it, which is why they target it early.
One of the most common weaknesses is running backup services under domain administrator credentials. Once an attacker compromises Active Directory, those same credentials often provide direct access to backup repositories and management consoles. Deleting backup catalogs or corrupting backup metadata then becomes a matter of minutes, not hours.
Backup repositories connected to the production network present another common risk. If the attacker has already moved through your production environment, a repository on the same network is typically reachable with the same compromised credentials. There’s no security boundary to stop them.
It’s also worth distinguishing between software-based retention policies and true storage-layer immutability. Many backup platforms offer retention locks that prevent accidental deletion. But those protections are often enforced by the backup application itself. If an attacker gets backup administrator privileges, they can modify or remove those policies before encryption starts.
Storage-layer immutability works differently. Technologies such as S3 Object Lock in COMPLIANCE mode, WORM storage, or physically air-gapped media enforce write-once protection independently of backup software. Even compromised admin credentials can’t override those controls until the retention period expires.
Attackers also know which backup products they’re likely to encounter. Many ransomware families maintain lists of backup-related services (Veeam, Acronis, Backup Exec) and terminate those processes before encryption starts.
The result shows up in the data. According to the Sophos State of Ransomware 2025 report, only 54% of organizations affected by ransomware were able to restore data successfully from their backups. That’s the lowest success rate Sophos has recorded in six years of research. The other 46% either paid the ransom, lost data, or are still recovering.
Recovery time: what the data shows
According to Veeam’s 2025 Ransomware Trends Report, the average recovery time from a ransomware attack is 24.6 days. More than half of organizations recover less than half of their data. Only 10% restore over 90%. Even when ransom payments are excluded, the average recovery cost still exceeds $1 million.
What’s striking is the gap between planning and execution. Nearly every surveyed organization (98%) reported having a documented ransomware response playbook. Fewer than half had the operational capabilities to actually execute that plan. That’s where most recovery efforts break down. Not because the teams failed to prepare on paper, but because the underlying backup architecture wasn’t designed to survive a real attack.
In practice, recovery speed depends as much on where your backups live as on whether they exist. Some tiers are optimized for fast operational recovery, others prioritize resilience over restore speed. Knowing the tradeoffs helps you set realistic expectations before an incident hits.
| Backup tier |
Typical restore speed |
Ransomware resilience |
| Local NVMe snapshots (storage-layer immutability) |
Very fast |
High, provided immutability is enforced at the storage layer |
| On-premises object storage with S3 Object Lock |
Fast, limited by disk and network |
High, because Object Lock remains effective even if admin credentials are compromised |
| Cloud backup with Object Lock |
Moderate, limited by inbound bandwidth |
High, although restoring very large datasets may incur significant egress costs |
| Air-gapped tape |
Slow due to sequential media access and retrieval time |
Very high, since the backup remains physically isolated from the network |
| Network share backup (no immutability) |
Fast |
Low, because attackers with compromised admin credentials can usually access the repository |
The fastest backup isn’t always the most resilient, and the most resilient isn’t always the fastest to restore. That’s why most organizations combine several tiers instead of relying on a single recovery target. Fast local immutable storage minimizes downtime during common incidents. Cloud Object Lock or air-gapped media provides the fallback if the primary backup infrastructure is compromised. The next sections break those architectures down.
The ransomware recovery process: step by step
Recovering from ransomware isn’t just restoring the latest backup. As said, each stage builds on the previous one. Skipping steps can leave the attacker inside your environment, or it can result in another encryption event within days of recovery. Here’s the order that actually works.
Step 1: Contain immediately
Isolate affected systems from the network as quickly as you can. Don’t shut them down unless you have to, because volatile memory may contain valuable forensic evidence, including encryption keys and malware artifacts.
Disable compromised service accounts. Block outbound communications from systems within the suspected attack scope.
Step 2: Assess the scope
Figure out which systems have been encrypted, which backup copies remain intact, and when those backups were created relative to the estimated compromise date. Don’t assume the newest backup is the safest. In many cases, older backups are cleaner.
Step 3: Begin required notifications
Regulatory reporting deadlines start the moment you detect the incident, regardless of how fast recovery progresses. GDPR requires notification of supervisory authorities within 72 hours when personal data has been affected. HIPAA, PCI DSS, DORA, and most cyber insurance policies impose their own timelines. Start these processes early, while technical recovery is still underway, so compliance doesn’t slip behind the technical work.
Step 4: Identify a clean restore point
Review endpoint telemetry, authentication logs, firewall logs, and other available evidence to estimate when the initial compromise happened. Whenever possible, restore from a backup created before the earliest indicators of compromise.
If historical telemetry doesn’t go back far enough, picking a restore point 7 to 14 days before encryption is often a reasonable starting point, though every incident is different. (The section on identifying a clean restore point covers this in more depth.)
Step 5: Build a clean recovery environment
Avoid restoring directly into the compromised environment. Prepare a separate recovery network with new administrative credentials that have never existed in the compromised Active Directory. If VMware or Hyper-V management was compromised, rebuild the hypervisor layer before hosting restored workloads.
Step 6: Restore from a verified immutable backup
Validate backup integrity before you attach restored systems to the recovery environment. After restoration, verify that applications, databases, and dependent services function correctly before reconnecting anything to production. Rushing this step is how teams end up with half-restored databases they can’t tell are corrupted.
Step 7: Eliminate the root cause before reconnecting
Recovery isn’t complete just because systems are online. If the original access vector is still open, whether it’s a compromised account, a vulnerable VPN gateway, or an unpatched service, the attacker will regain access and encrypt the environment again within days. This is one of the most common causes of repeat ransomware incidents, and it’s why the post-recovery section below treats root-cause elimination as a prerequisite for declaring the incident over.
Step 8: Reconnect with enhanced monitoring
Before returning workloads to production, deploy endpoint detection and response (EDR) tools together with enhanced network monitoring. Assume attacker persistence is possible until the investigation is complete and the environment has been fully remediated. Even if you’ve done everything right, a second encryption event is a real risk if you skip this step.
Backup architecture that survives ransomware
Recovering from ransomware starts long before the attack itself. The architecture you build today determines whether recovery takes hours, weeks, or, in the worst case, becomes impossible. There’s no way to improvise it during an incident.
A good starting point is the 3-2-1-1 backup rule: maintain three copies of your data, store them on two different media types, keep one copy offsite, and make one copy immutable or air-gapped. The last requirement is what makes the biggest difference during a ransomware incident. An attacker who has compromised domain administrator credentials can usually reach every backup connected to the production network. An immutable or physically isolated copy survives because it removes that attack path entirely.
Backup infrastructure also deserves its own security boundary. Backup service accounts should never be members of the production Active Directory domain. Use a dedicated backup domain with no trust relationship, or standalone local accounts that have no connection to production authentication. Backup traffic should run on a dedicated VLAN that production workloads can’t reach directly.
Retention policies deserve just as much attention. Modern ransomware campaigns often stay undetected for several days before encryption begins, so retention needs to account for attacker dwell time, not just accidental deletion. Daily backups retained for at least two weeks cover the current median dwell time. Monthly backups retained for a year protect against slower-moving compromises that can remain hidden for months.
Immutable and air-gapped backups
Not all “immutable” backups provide the same protection. What ultimately matters is storage-layer immutability.
With technologies such as S3 Object Lock in COMPLIANCE mode, objects are protected for a defined retention period during which no user, not even the root account, can modify or delete them. Enforcement happens at the storage layer, not within the backup application, so compromised admin credentials can’t bypass the protection.
This distinction matters during a real attack. If immutability depends only on backup software policies, an attacker with backup administrator privileges may still be able to remove or modify those protections before encryption starts.
Organizations that can’t store backup data in the public cloud still have options. DataCore Swarm provides S3-compatible object storage with Object Lock support for on-premises deployments, which lets regulated industries like healthcare, defense, or financial services operating under DORA keep immutable backup targets without moving data offsite. Comparable options exist from MinIO (community edition), Scality Ring, and Cloudian HyperStore, all of which support S3-compatible Object Lock on-premises.
Air-gapped tape represents the opposite end of the spectrum. By physically separating the backup media from the production network, it eliminates any network path an attacker could exploit. The tradeoff is recovery speed. Sequential media access and physical tape retrieval make restores considerably slower for large datasets, but the resilience is hard to match.
For most organizations, the best design combines multiple layers of protection rather than relying on a single technology. Local immutable snapshots provide the fastest operational recovery. On-premises object storage with Object Lock is the primary backup repository. Tape or cloud Object Lock provides the final recovery copy if everything else fails.
How to identify a clean restore point
One of the biggest mistakes during ransomware recovery is assuming the newest backup is the safest. With a median attacker dwell time of around five days, the latest backup may already contain compromised systems or persistence mechanisms.
Finding a clean restore point starts with determining when the earliest indicators of compromise appeared. Endpoint telemetry, authentication logs, and firewall logs often reveal suspicious activity well before encryption begins. Unusual lateral movement, privileged account activity outside normal hours, large-scale file enumeration, or attempts to disable security tools all help establish the likely intrusion timeline.
Your backup infrastructure can provide useful clues too. Failed backup jobs, unexpected retention policy changes, backup catalog deletions, or unusually large data changes shortly before encryption may align with attacker activity. When you correlate these events with endpoint telemetry, you can usually narrow down the safest restore window with much more confidence.
If historical telemetry doesn’t extend far enough back, restoring from a backup created seven to fourteen days before encryption is usually a reasonable starting point. Even then, enhanced monitoring after recovery remains essential to catch any persistence that may have survived.
Setting up an isolated recovery environment
Where you restore systems matters just as much as what you restore. Rebuilding compromised workloads inside the same environment that was attacked often recreates the original problem, especially if attacker persistence hasn’t been eliminated.
Build a dedicated recovery environment with its own network segment, completely isolated from production. Use new administrative credentials that have never existed in the compromised AD environment. Wherever possible, restore workloads onto clean hypervisor hosts.
If shared storage or virtualization management was also compromised, connect only validated backup repositories that originate from trusted, isolated backup infrastructure.
Resist the temptation to restore everything at once. A staged recovery is usually both faster and safer. Start with the minimum set of systems required to resume critical business operations, verify that those services function correctly, and then restore additional workloads in phases. Under incident pressure, attempting a full-scale recovery in a single step often creates problems that are difficult to diagnose later.
Testing ransomware recovery
A recovery plan is only as good as the last time you proved it works. If you’ve never restored production-scale data under realistic conditions, your actual RTO is an estimate, not a measured capability.
It’s becoming a regulatory expectation as well. DORA, which has applied to EU financial entities since 17 January 2025, requires organizations to perform and document operational resilience testing, including recovery procedures. A disaster recovery document full of theoretical RTO values doesn’t satisfy that requirement.
Meaningful testing goes beyond verifying that backup jobs complete successfully. It restores representative production datasets into an isolated environment, measures actual recovery time, confirms application functionality, and verifies that the selected restore point predates the simulated compromise.
Tabletop exercises still matter because they test communication, coordination, and decision-making during an incident. Live recovery drills test the infrastructure itself. You need both. Neither replaces the other.
In practice, one gap shows up more often than any other: backup reports show successful job completion, but no one has ever measured how long a full production restore actually takes.
Cloud, on-premises, and hybrid recovery models
There’s no universal recovery model that fits every organization. The right approach depends on your workloads, regulatory requirements, recovery objectives, and available infrastructure.
Cloud recovery makes it possible to deploy isolated recovery environments quickly while keeping backup copies geographically separated from production. That flexibility comes with practical costs, including cloud egress charges, bandwidth limitations during large-scale restores, and shared-responsibility boundaries that define which parts of the recovery environment stay under the cloud provider’s control.
On-premises recovery offers a different set of tradeoffs. Keeping backup data local enables high-speed restores across the LAN and avoids large-scale data transfers. At the same time, you’ll need enough clean hardware available for recovery, and that infrastructure must sit outside the scope of the original compromise.
For many organizations, a hybrid approach provides the best balance. Immutable on-premises backups support fast operational recovery for the most common ransomware scenarios. Cloud Object Lock storage provides an extra layer of geographic resilience if an entire site becomes unavailable.
Finally, don’t overlook compliance requirements when designing the recovery architecture. HIPAA, GDPR, and DORA may restrict where backup copies are stored and where recovery environments can process regulated data. Before an incident occurs, verify that your recovery environment satisfies the same residency and compliance requirements as your production systems.
Post-recovery security enhancements
Getting systems back online doesn’t mean the incident is over. If you restore workloads into the same security posture that allowed the original compromise, you’ll likely be dealing with another incident in the near future. Recovery should always be followed by hardening the environment before normal operations resume.
Start by resetting credentials across the entire infrastructure, not just the accounts you know were compromised. Service accounts, scheduled task credentials, backup agent accounts, and machine passwords on restored systems should all be treated as potentially exposed.
Administrative privileges deserve another look. Separate workstation administration, server administration, and domain administration into different identities with independent credentials. Add privileged accounts to the Active Directory Protected Users group to reduce credential caching and limit pass-the-hash attacks, and protect those accounts with hardware-backed multi-factor authentication wherever possible. FIDO2 security keys currently provide one of the strongest phishing-resistant authentication options.
Before reconnecting restored systems to production, deploy endpoint detection and response (EDR) across every endpoint together with network monitoring and anomaly detection. Even if you’ve picked a clean restore point, assume some persistence mechanisms could remain undiscovered until the investigation is complete.
Finally, review the external attack surface before declaring recovery complete. Patch VPN appliances, disable unnecessary external RDP access, and review firewall rule changes made in the weeks leading up to the incident. Many organizations also benefit from an independent security assessment at this stage, since fresh eyes often identify issues that internal teams overlook while working under incident pressure.
Common ransomware recovery mistakes
Even organizations with mature backup strategies make avoidable mistakes during recovery. Most of them happen because teams are working under enormous pressure to restore services as quickly as possible.
The mistake behind the largest number of repeat infections is restoring systems into the same compromised environment before eliminating the original access vector. This is covered in detail in Step 7 above. The short version is that an attacker with persistent access will re-encrypt restored workloads faster than the team that just finished recovering them.
Another common assumption is that a successful backup job guarantees a usable backup. A backup created by a compromised backup agent may complete successfully while still capturing corrupted or compromised data. Backup logs tell you the job ran. They don’t tell you the data is clean or that a full restore will succeed. The only reliable validation is to test the restore itself.
It’s also tempting to view ransom payment as a recovery strategy. In practice, decryption tools supplied by ransomware groups frequently produce incomplete recovery, corrupted files, or simply fail to work. Paying the ransom does nothing to remove the attacker’s access or recover stolen data. If your backup architecture survives the attack, restoring from verified backups while negotiations proceed is usually the faster and more reliable path.
Restore time is another area where expectations diverge from reality. Under real incident conditions, you’re rarely restoring a single virtual machine. You may need to rebuild infrastructure first, identify a clean restore point, validate backup integrity, and recover dozens of interconnected systems simultaneously. Actual ransomware recovery times often exceed the recovery objectives documented in traditional disaster recovery plans.
Finally, don’t declare the incident closed simply because applications are running again. If the root cause hasn’t been identified and eliminated, restored systems may still contain persistence mechanisms or reconnect to infrastructure the attacker can access.
Current ransomware trends
Ransomware continues to evolve. The changes over the past year point in the same direction: attackers are becoming faster, more automated, and harder to defend against.
CrowdStrike’s 2025 Global Threat Report documented a 75% year-over-year increase in cloud-environment intrusions, much of it driven by initial-access brokers selling footholds to ransomware affiliates. AI-assisted reconnaissance is accelerating the early stages of an attack. Automated tools can map Active Directory environments, identify backup infrastructure, and prioritize high-value systems much faster than manual reconnaissance alone.
Ransomware-as-a-Service (RaaS) has lowered the barrier to entry. Many attacks are now carried out by affiliates using mature toolkits developed by specialist groups, including names that recur in takedown notices like LockBit, BlackCat (ALPHV), and Akira. That model has increased attack volume without reducing the sophistication of individual incidents.
Extortion techniques keep evolving. Triple extortion has become increasingly common, combining encryption, data theft, and direct threats to contact customers, partners, or regulators. Even organizations that recover successfully from immutable backups still face a separate data-exposure incident.
Healthcare and other critical infrastructure organizations remain among the most targeted sectors. Operational disruption creates immediate pressure to restore services, while protected health information and operational data retain significant value on the black market.
Managed service providers (MSPs) have become increasingly attractive targets. By compromising a single provider, attackers may gain access to dozens or even hundreds of customer environments. Any MSP with access to backup management, monitoring platforms, or privileged administration should follow the same credential isolation and security practices as internal administrators.
Regulatory expectations continue to increase. Frameworks such as DORA, NIS2, and emerging US regulations increasingly emphasize demonstrated recovery capability instead of documented procedures alone. For organizations in regulated industries, regular live recovery exercises are now both an operational necessity and a compliance requirement.
Conclusion
By the time ransomware encrypts your servers, most of the important recovery decisions have already been made. Your backup architecture, credential isolation strategy, recovery procedures, and testing program determine whether recovery is measured in hours, weeks, or months. None of those decisions should be improvised while an incident is unfolding.
As ransomware campaigns grow more sophisticated and regulatory requirements tighten, preparation is no longer a differentiator. It’s a baseline expectation. The organizations that recover fastest aren’t the ones with the most sophisticated tools. They’re the ones that rehearsed the worst day of their year before it arrived, that kept backup credentials outside the production domain, and that proved their RTO with a live restore instead of a slide deck. Start there. Schedule the first real test before the end of the quarter, document the actual restore time, and fix the gap between what your playbook claims and what your infrastructure can deliver.
FAQ
What is ransomware recovery?
Ransomware recovery is the process of restoring systems, data, and business operations after servers or storage have been encrypted by ransomware. Recovery success depends largely on whether your backup infrastructure was designed to withstand targeted attacks against the backups themselves.
Should you pay the ransom?
Most cybersecurity agencies recommend against paying. Decryption tools supplied by ransomware groups are often unreliable, and payment neither removes the attacker’s access nor prevents stolen data from being leaked. If verified backups are available, restoring from them is generally faster and more predictable.
Why do backups fail during ransomware attacks?
The most common causes include backup services running under compromised domain administrator accounts, backup repositories that remain accessible from the production network, and software-based immutability that attackers can disable using stolen administrative credentials. According to industry research, attacks against backup infrastructure succeed surprisingly often, which is why storage-layer immutability and credential isolation have become critical design principles.
Does DORA require ransomware recovery testing?
Yes. Since 17 January 2025, DORA has required EU financial entities and relevant ICT service providers to perform and document operational resilience testing, including recovery procedures. Organizations need to demonstrate that recovery objectives can be achieved under realistic conditions rather than relying solely on documented disaster recovery plans.
from StarWind Blog https://ift.tt/iqvDzOM
via
IFTTT
