Your Recovery Time Is Longer Than You Think

Ask most organisations how long it would take to recover from losing their main server and you will get a number. Ask where the number came from and the answer is usually that it was agreed when the plan was written, or that it is what the business said it needed. Neither of those is a measurement. The gap between an assumed recovery time and a real one is where most recovery projects go wrong, and it is almost always in the same direction.

Backups run overnight, incrementally, with nobody waiting. A restore is a full write of everything, often over the same link, frequently from compressed and deduplicated storage that has to be reassembled as it goes. Restoring from cloud or off-site storage adds download time that the backup schedule never had to account for. It is worth calculating, at minimum, how many hours it takes to move the full data volume at the speed of the link it has to travel over.

Almost nothing restores in isolation. Authentication has to be working before most services will start. Databases have to be up before applications. Applications often need licence servers, certificates or specific hostnames and addresses. Restoring the right systems in the wrong order means restoring some of them twice, and the dependency map is usually in somebody's head rather than in the plan.

If the original hardware is encrypted, seized as evidence or physically destroyed, the restore needs somewhere else to go, and that hardware or cloud capacity has to be procured, built and configured before recovery even begins. Plans that assume a restore onto the existing server quietly assume the existing server is available. After a serious ransomware incident it usually is not, because rebuilding clean is the whole point.

Backup console logins, licence portal passwords, cloud administrator accounts, MFA tokens and vendor support contract numbers are commonly stored in a password manager, a file share or a documentation system that is part of the environment being recovered. An offline copy of the credentials and contacts needed to start a recovery is a small piece of preparation that removes a genuinely common source of delay.

Recovery speed frequently depends on a single individual who built the environment. If the incident happens while they are on leave, unreachable or have left the organisation, every step takes longer and some steps do not happen at all. A useful test of any runbook is whether a competent person who did not write it could follow it without making phone calls.

A ransomware recovery is not a restore. Before data goes back, the entry point has to be understood and closed, or the same attacker returns to a freshly restored environment. Systems are rebuilt rather than restored wholesale, to avoid reintroducing what was there. Credentials are reset broadly. Insurers and, depending on jurisdiction, regulators may need to be notified, and evidence preserved. These steps run alongside recovery and extend it.

Business downtime begins at the moment of failure, not at the moment IT begins recovery. Detection, escalation, investigation, the decision to declare a disaster and the decision about which systems come first all consume real hours, often overnight or at a weekend. A four-hour technical restore that starts nine hours after the failure is a thirteen-hour outage to everyone else.

Recovery point matters as much as recovery time. A restore to last night's backup means every transaction, order and record created since then must be re-entered or reconstructed, and somebody has to know what they were. For some businesses that work takes longer than the technical recovery did, and it is rarely counted in the recovery target.

None of this requires a full failover exercise to find out. Restoring one significant system to isolated hardware and timing it honestly, including the fumbling, usually reveals most of the gaps above in a single afternoon. The outcome that matters is not a pass or fail but a number you can defend, and a short list of what to fix to shorten it.

Where the answer turns out to be uncomfortable, it is better to have it now than during an incident. A readiness assessment is simply that exercise done independently, and we report what we find rather than what would be reassuring.