How long does it actually take to recover from ransomware with tested backups
If you have backups you have tested, recovering from ransomware usually takes a few days of focused work once the attack is contained, and the copying of data back is rarely the slowest step. The time goes to cleaning up the machines, checking that what you restore is good, and getting people back to work. Untested backups can turn that same job into weeks, because you find the problems while you are already in the middle of the emergency.
Where the time actually goes
Most recoveries move through the same stages, and it helps to know them before you are in one. The first stage is containment. You disconnect infected computers from the network, shut down anything that is still encrypting files, and work out which systems were hit. This often takes the first day, and it is worth doing carefully because a machine you miss will infect the restored data again.
The second stage is rebuilding or cleaning the affected machines. For a lot of small offices, the safest choice is to wipe the infected computers and reinstall the operating system from a clean image, not try to remove the malware by hand. A clean reinstall on a single laptop might take an hour or two. Doing it for a dozen machines takes a day or more, mostly because each one needs its updates, its software, and its settings put back.
The third stage is restoring the data. This is the part most people picture, and it is often the shortest. Copying files back from a backup depends on how much data there is and how fast the storage and network are. Verification comes next, opening sample files, checking that the accounting database loads, and making sure nothing is still encrypted. The last stage is reconnecting, changing passwords, and turning on the monitoring you should have had in place already.
How to estimate your own number
You can get a rough figure for your own business with simple arithmetic. Take the amount of data you would need to restore, divide it by the speed you can actually restore at, and add the time you expect to spend rebuilding machines and checking results. The speed matters more than people expect. A restore that moves 100 GB an hour is a very different job from one that moves 10 GB an hour over a slow connection.
Here is an example with made-up numbers. Suppose you have 500 GB of business data, your backup restores at about 100 GB an hour, and you need to rebuild five computers at roughly two hours each. The data restore is about five hours. The rebuilds are about ten hours, and some of that can happen at the same time as the data restore. Add a few hours for containment, checking, and reconnecting, and you have a plan that is measured in working days, not weeks. Your own figures will be different, but the method is the same.
Write these numbers down. Most of the planning value is in knowing your restore speed before you need it.
What a tested backup changes
A backup you have never restored is a hope, not a plan. The usual surprises are predictable. The backup is missing the newest files because a job quietly failed months ago. The backup itself was encrypted by the attack because it was always connected to the network. Nobody remembers the password for the backup software. The restore runs, but the database inside it is corrupted. Each of these can add days to the timeline, and they tend to show up all at once when you are already stressed.
A test restore finds these problems on a normal day. Pick a set of files, restore them to a separate location, and open them. Once or twice a year, do a fuller test: restore a whole machine or a whole shared folder and time it. Those timings are the numbers you will use in the estimate above, so the test does two jobs at once.
Keep at least one copy of your backup offline or otherwise cut off from the network that the attackers could reach. If you can only do one thing, do this. It is the difference between restoring from a clean copy and having no copy at all.
Your next step
Set aside an hour this month. Choose a folder that matters to your business, restore it from your backup to a spare location, and write down how long it took and whether everything opened properly. Then ask yourself how long a full restore would take, using the arithmetic above. If the answer is longer than you can afford to be down, that is the thing to fix first, whether that means a faster backup target, a second copy, or a clearer plan for who does what on the day.
A test that takes an hour now is far cheaper than discovering your backups do not work in the middle of an attack.