Ransomware recovery time: how long it really takes an office to get back, and how to shorten it

Ask an office how long it would take to get back to work after ransomware, and the answer is usually “we have backups”. There is a NAS in the server room that the vendor set up, a cloud backup someone renews every year, and an email every morning that says the job succeeded.

That is the right first answer. It decides whether the data comes back at all. It does not decide when. That depends on how fast the copy can be read, how many servers have to be rebuilt around it, and how long it takes everyone to agree on what has happened before anyone touches a keyboard.

The survey numbers say the same. Sophos’s State of Ransomware 2025 asked 3,400 organisations of 100 to 5,000 people, in 17 countries, that had been hit in the previous year. 16% were fully back within a day, 53% within a week (up from 35% a year earlier), and 97% within three months. And where data was encrypted, backups were used to restore it in only 54% of incidents, the lowest share in the six years Sophos has asked. So for a typical mid-sized company, a week is not the pessimistic number. It is the middle.

1 · Where the hours actually go

A recovery has four parts, and the restore itself is often not the longest:

• Noticing and deciding. Someone sees the ransom note on Monday morning. Then come the calls: the IT person, the vendor, the director. Is it one laptop or the whole file server? Do we switch everything off? Who rings the insurer? Four hours here is quick.
• Getting the copy back. If the backup is on disks in a cupboard at another office, or at the director’s house, someone has to drive and fetch them.
• The restore. Data divided by speed. A NAS on the office network can write a hundred-odd megabytes a second. A cloud backup comes back through your internet line, and a 200 Mbps line, used at 70%, moves about 17.5 megabytes a second.
• Rebuilding the servers. Each server has to be reinstalled or checked, the application started, the licences and drive mappings sorted, and someone has to confirm Tally or the ERP opens on yesterday’s figures.

Here is one office of fifty people, with 2 TB to restore and six servers, worked through three ways. Same data, same two engineers, only the place the backup lives changes.

The cloud copy is the safe one, and that matters. But on its own it is rarely the fast one. Two days of restore over the internet line comes as a surprise to most offices, because nobody has ever restored more than a single folder from it.

2 · The copy that has to survive

Speed only matters if there is something left to restore. Someone who gets hold of an admin password will usually look for the backups before encrypting anything, because deleting them is what makes the ransom worth paying. In many Indian offices that is easy: the NAS is joined to the domain and shares the same administrator password as everything else, and the backup console has no second factor.

The rule backup people use is 3-2-1-1-0: three copies of the data, on two kinds of storage, one of them offsite, one that is offline or immutable (no admin password can delete it before a set date), and zero errors when a restore is tested. Plenty of offices have the first three. The last two are the ones that decide the outcome.

3 · The clock that runs alongside the restore

Ransomware is named in CERT-In’s list of incidents that must be reported. Its directions of 28 April 2022 give organisations six hours from noticing an incident to report it, and ask for 180 days of logs kept in India, so that there is something to look at afterwards. That six hours falls inside the “noticing and deciding” step above, not after the restore.

Restoring also does not settle whether data was copied out first. Sophos found that 28% of organisations whose data was encrypted also had it stolen. If personal data of customers or staff went with it, the breach duties of the DPDP Rules apply too, from 13 May 2027. A quick restore is half the job, and the incident is not closed when the file server comes back.

4 · Five ways to shorten it, starting this month

1. Time one real restore. Pick one server, pick a Sunday, and use a stopwatch. The megabytes a second you actually get is the most useful number in this article, and most offices have never measured it.
2. Keep a local copy for speed and a locked copy for safety. A NAS or backup server on site for the fast restore, and a cloud or offline copy that cannot be deleted for the bad day. One copy cannot be both.
3. Take the backups out of the domain. Separate login, a second factor on the backup console, and an admin password that is not the one on every other machine.
4. Write the restore order on one page. Which system comes back first (usually Tally or the ERP, then the file server, then everything else), and who decides. That page saves hours in the first morning.
5. Decide now who calls CERT-In. A name, a backup name, and the address (incident@cert-in.org.in) written down, so the six-hour clock is somebody’s job before it starts.

Our free ransomware recovery calculator does the arithmetic for your own office: put in your data size, servers, where the backup lives and your internet line, and it shows the recovery time step by step, what the outage would cost in rupees, and how your backups measure against 3-2-1-1-0. Once you have timed a restore, replace our working figures with your own. Everything stays in your browser.

Questions people ask