What Is Ransomware Recovery? Process, First Steps and What to Do When Backups Are Encrypted

Ransomware recovery is the work of getting an organisation's data, systems and operations back after ransomware has encrypted them. It covers containing the attack, finding out what was affected, getting the data back, rebuilding the systems on a clean footing and making sure the attacker cannot simply return.

There are two ways to get the data back. The first is restoring from backups that the attacker did not reach. The second, when the backups were encrypted or deleted as well, is recovering the data directly from the encrypted files. Most articles on ransomware recovery only describe the first. As a lab that has handled 656+ ransomware cases, we see the second every week, so this guide covers both.

Ransomware recovery is not one task but several running side by side: incident response (stopping the attack and removing the attacker's access), data recovery (getting the files, databases, virtual machines and backups back), system rebuild (reinstalling or restoring servers on clean infrastructure) and business recovery (bringing applications back in the right order so the business can work again).

The goal is to resume operations with as little data loss as possible, without paying the ransom where that can be avoided, and without restoring the infection along with the data. That last point is why ransomware recovery needs more care than an ordinary restore.

1. Contain. Disconnect the affected servers and storage from the network and disable the accounts the attacker used. Do not power off, wipe or reinstall anything yet: the encrypted disks are both the evidence and, often, the source of the data you will recover.

2. Preserve. Keep the ransom note, a few encrypted files, the logs and, if possible, images of the affected disks. If you have unencrypted copies of the same files from before the attack, keep those too: comparing the two shows exactly how the ransomware encrypted.

3. Assess. Establish which systems were hit, which ransomware family it is, when the attack started, and the state of every backup, snapshot and replica. The question that decides everything else is: is there a clean, complete backup from before the attack?

4. Choose the recovery path. If clean backups exist, plan the restore. If they do not, or they are incomplete, measure how much of each important file was encrypted and what the untouched parts still hold. Large databases, virtual disks and backup files are often only partly encrypted.

5. Recover the data. Restore from clean backups, recover data from the encrypted files, or combine the two: for example, restore last week's backup and recover the newer records from the encrypted database.

6. Rebuild and validate. Bring systems back on clean or rebuilt infrastructure, starting with identity (Active Directory), then databases and core applications. Check that restored data is complete and that no attacker tools came back with it before reconnecting to the network.

7. Return to operations and review. Reconnect users, monitor closely, and record how the attacker got in and what slowed the recovery, so the same entry point and the same weak backup are not there next time.

Isolate, but do not destroy. Unplug network cables or disable switch ports rather than shutting machines down, and do not format, reinstall or run cleaning tools on the encrypted servers.

Do not run decryptors or recovery tools downloaded from the internet on your only copy of the data. A wrong tool can damage files that were still recoverable. Work on copies.

Check the backups at once and take them offline. Attackers routinely delete or encrypt backups; a backup server still connected to the network may be hit a second time.

Use a separate channel to communicate (phone, a personal messaging group) if email or the domain is compromised. Inform your management, your cyber insurer if you have one, and the authorities where the law requires it; in India, report to CERT-In.

Get the recoverability question answered early. Whether the data can come back from backups or from the encrypted files themselves decides every later choice, including whether the ransom question even arises.

Disaster recovery plans were written for fire, flood, hardware failure and human error. They assume the backups are intact and the threat is over once the disaster has passed. Neither is true for ransomware.

A ransomware attacker is deliberate: they look for the backups and delete or encrypt them first, they may have been inside the network for days or weeks before encrypting, and they may still have access during the recovery. So ransomware recovery adds steps that ordinary disaster recovery does not have: checking that the restore point is from before the attacker got in, rebuilding rather than just restoring, and a fallback when there is no clean backup at all.

That fallback is data recovery from the encrypted files, and it is where a disaster recovery plan alone stops working.

This is the situation most of our clients are in when they contact us: the servers are encrypted, the Veeam or other backup files are encrypted or deleted, and there is no offline copy. It is far from hopeless.

Modern ransomware encrypts large files only in part, to finish before anyone notices. Some families encrypt only the first part of each file, others encrypt in stripes with untouched gaps in between. In one LockBit 3.0 case we measured, only 3.76% of a 1.1 GB file had actually been encrypted. A database, a virtual disk or a backup file of tens or hundreds of gigabytes therefore usually still holds most of its data in readable form.

Recovery works from those untouched parts, without the attacker's key: SQL Server and Oracle tables are rebuilt from intact database pages, files are extracted from the readable regions of VMware VMDK and Hyper-V VHDX disks, and the intact data blocks are read out of encrypted Veeam VBK and VIB backups. In a 70 GB Akira-encrypted Veeam backup, 62% of the data was readable and recovered this way.

Small files such as documents and photos are usually encrypted completely; those come back only from backups, shadow copies, older copies on other machines, or a working decryptor where one exists.

In many cases, yes. The routes are clean backups and snapshots, recovery from the unencrypted parts of large files, and, for some older or flawed families, a working decryptor. Modern ransomware cannot be decrypted without the attacker's key, so be wary of anyone who claims to break the encryption itself.

Paying does not guarantee recovery either: attackers' decryptors are often slow, crash on large files, or damage databases and virtual disks. Whatever you decide, establish first what can be recovered without paying. That answer is often enough to make paying unnecessary.

With clean, tested backups and a practised plan, critical systems can be back within hours to a day or two. Without usable backups it takes longer, because the data has to be recovered from the encrypted files first: a single database or backup file typically takes a few days, a full environment of servers, virtual machines and backups one to two weeks.

What speeds it up most is acting early and not making things worse: no reinstalling, no overwriting the encrypted disks, and getting the encrypted files to a recovery lab while they are unchanged.

Keep at least one backup copy the attacker cannot reach: offline, or immutable for a fixed period. Use separate credentials for the backup system, never domain admin accounts, and protect them with multi-factor authentication.

Test restores regularly, including a full restore of your most important database and virtual machine. A backup that has never been restored is only an assumption.

Write down the recovery order (identity, databases, core applications, file shares) and who decides what, and keep a printed copy: during an attack the documentation server may be encrypted too.

Our lab in Dharmapuri, Tamil Nadu recovers data from ransomware-encrypted servers, SQL Server, Oracle, MySQL and Tally databases, VMware and Hyper-V virtual machines, NAS devices and Veeam backups, for clients in India and abroad. We have solved many cases like yours, with LockBit, Akira, Phobos, Makop, Medusa and many other families.

Every case starts with a free assessment: we measure the encryption on your files and tell you what can be recovered before any work is agreed. No data, no charge, and an NDA on request. Under attack right now? Call or WhatsApp us 24/7.