881 Most ransomware recovery plans are written as protection plans. They specify where backups land, how long they are retained and which retention lock is enforced. They are reviewed, approved and filed. Then an incident happens and the question nobody wrote down turns out to be the only one that matters: how many hours until the business is running again. Protection and recovery are not the same discipline. Protection is a write-path property — it is configured once and verified by inspection. Recovery is a read-path property under load, and it is only verified by doing it. An architecture can be flawless on the first and unproven on the second, which is the position a lot of organizations discover they are in on the worst possible day. This guide is about the second half. It covers how to express recovery speed as a number you can defend, why object storage changes the arithmetic, and the four architectural properties — immutability, isolation, parallelism and validation — that determine whether that number is real. What is ransomware recovery? Ransomware recovery is the set of processes and technologies used to restore data and resume operations after a ransomware incident, without relying on the attacker. It differs from ordinary backup restore in one respect: the recovery infrastructure itself is assumed to be a target. That assumption changes the requirements. A working plan has to deliver: Point-in-time recovery — consistent restore points, not just retrievable files Immutable protection — backup copies that cannot be altered or deleted, including by an administrator Isolation — a restore path that does not depend on the compromised control plane Restore throughput at scale — measured in recovered workloads, not gigabytes per second Validation — evidence, generated on a schedule, that restore points actually restore Paying a ransom does not substitute for any of these. Decryption tools supplied by attackers are frequently slow, partial or corrupt, and they do nothing about the systems that were deleted rather than encrypted. Restoring from trusted copies is the only path that terminates. Measure recovery in workloads per hour, not gigabytes per second Throughput figures are the standard currency of storage procurement, and they are close to useless for recovery planning. A repository that sustains 10 GB/s in a sequential benchmark tells you nothing about how long it takes to bring 400 virtual machines back online, because that operation is bounded by concurrency, metadata operations and the backup application’s own scheduling long before it is bounded by raw bandwidth. The metric that maps to the business is workloads restored per hour — usually expressed as VMs per hour. It is the only figure that converts directly into a recovery time objective, and it is the figure an executive can act on. A model you can run against your own environment The arithmetic is simple enough to do on a whiteboard, and doing it is more informative than most vendor benchmarks. Take an environment of 400 VMs averaging 200 GB each — 80 TB to recover. Concurrent restore streamsEffective aggregate rateVMs per hourTime to restore 400 VMs40.8 GB/s~14~28 hours163.2 GB/s~58~7 hours6412.8 GB/s~230~1.7 hoursIllustrative model assuming 200 MB/s per stream and linear scaling. Real environments diverge — the point is the shape of the curve, not the absolute values. Three things follow from this. First, the difference between a two-hour recovery and a two-day recovery is concurrency, not bandwidth — the per-stream rate is identical in all three rows. Second, no realistic environment scales linearly to 64 streams; something saturates first, and identifying what saturates is the actual planning exercise. Third, if you cannot state your own number in this format, you do not have a recovery time objective. You have an aspiration. This is also where the distinction between RTO and RPO stops being academic. Recovery point objective is a function of backup frequency and is usually well controlled. Recovery time objective is a function of restore concurrency and is usually not measured at all. For the underlying definitions, see RTO vs RPO: key differences explained. Why object storage changes the restore arithmetic Object storage became standard in backup architectures because it scales capacity cheaply. Its relevance to ransomware recovery is different and more specific: it is a flat, parallel-by-default namespace with enforceable retention, which is close to an exact match for what a mass restore needs. Parallelism is an architectural property, not a tuning parameter A hierarchical filesystem serializes on directory metadata. Every restore stream contends for the same namespace structures, and the contention gets worse as concurrency rises — which is precisely backwards for a mass recovery event. An S3-style flat namespace has no directory tree to lock. Restore streams are independent by construction, so adding streams adds throughput until the network or the backup application becomes the constraint. That is the mechanism behind the table above. Moving from the first row to the third is not a matter of buying faster disks. It is a matter of whether the repository can absorb 64 simultaneous readers without the namespace becoming the bottleneck. More on the underlying behaviour in object storage throughput and enterprise resilience operations. Immutability that survives a compromised administrator Most recovery failures are not slow recoveries. They are absent recoveries — backups that were deleted, encrypted in place, or had their retention quietly shortened weeks before the encryption event. Object storage addresses this with retention enforced at the storage layer rather than the application layer. S3 Object Lock implements write-once-read-many semantics: within the retention period, an object cannot be modified or deleted by any credential, including root. The distinction that matters operationally is between governance mode, which a sufficiently privileged identity can override, and compliance mode, which nobody can. The failure mode to design against is not “we forgot to enable immutability.” It is “immutability was enabled in a mode that the attacker’s stolen credentials could turn off.” We have covered the mechanics in more depth in true immutability with S3 object storage. Retention has to outlast your detection gap Retention duration is usually set from a compliance requirement. For ransomware it should be set from dwell time — the interval between initial compromise and detection, which routinely runs to weeks. If retention is 14 days and the attacker was present for 30, every immutable copy you hold may already be poisoned. Immutability preserved the wrong state perfectly. Set retention against the detection gap you actually observe, not the one you would prefer. This is the same reasoning that applies to slow-burn compromise generally — see zero-day attack recovery. Safe copy isolation: separating the recovery path from the attack path Immutability protects the bytes. It does nothing about the path you use to reach them. Safe copy isolation is the practice of keeping at least one recovery copy reachable through a path that shares no identity, network or control plane with production. The test is simple: if the domain is compromised and every production credential is assumed hostile, can you still mount and read a backup? In a large number of architectures the honest answer is no, because the backup catalogue, the repository credentials and the restore console all authenticate against the same directory the attacker now controls. Isolation is layered, and the layers are independent: Identity isolation — recovery credentials issued from a separate identity provider, not the production directory Network isolation — a logical air gap between production and the repository, with the repository unreachable from a compromised production segment Control plane isolation — retention policy administered somewhere the backup server cannot reach Blast radius containment — no single compromised identity able to affect every copy, which is a fault domain question applied to administrative privilege rather than hardware A useful design heuristic: assume full credential compromise, then ask which copies survive and which restore paths still function. Anything that fails the test is protection theatre. Clean room recovery: where restored data goes Restoring a compromised VM into a compromised network re-infects it. This is not hypothetical; it is one of the more common ways a recovery attempt fails on the first pass and costs a day. A clean room is an isolated environment — separate network segment, separate identity, no route back to production — where restored workloads are brought up, scanned and validated before they are returned to service. It gives you somewhere to answer the question that determines the whole recovery timeline: which restore point is the last known good one? Without a clean room, finding that restore point means restoring candidates into production and observing what happens. That is both slow and dangerous. With one, the search is a parallel background activity that runs while the rest of the recovery proceeds. Note that this changes the throughput requirement: a clean room implies restoring the same data more than once, and the repository needs to absorb that without stalling the primary recovery. Restore testing: the only evidence that any of this works Backup job success is a write-path signal. It confirms bytes were transferred. It says nothing about whether those bytes constitute a bootable, application-consistent system, and a green dashboard full of successful jobs is entirely compatible with a repository that cannot restore anything. Restore testing closes that gap, and it has to be graded, because the cheap tests do not prove much: Object-level verification — checksums and retention state. Continuous, low cost, proves the data is intact. Single-workload restore — one VM restored and booted. Weekly. Proves the pipeline functions end to end. Application-consistent restore — a database restored and queried. Monthly. Proves point-in-time consistency, not just file retrieval. Mass parallel restore — dozens of workloads at once, timed. Quarterly. This is the only test that produces a defensible VMs-per-hour figure. Full isolated recovery — an environment rebuilt in a clean room using only isolated copies and out-of-band credentials. Annually. Proves the isolation is real. Most organizations run the first two and report themselves as tested. The last two are where architectures fail, which is exactly why they get skipped — they are disruptive, and they produce uncomfortable numbers. Those numbers are the deliverable. Backup tiers and where recovery speed actually lives Backup architectures are commonly tiered: a performance tier for recent restore points, a capacity tier for cost-effective scale and a long-term tier for retention and compliance. For a long time object storage was assumed to belong in the second and third tiers only. That assumption is now out of date — backup vendors validate object storage at the performance tier, including for instant recovery, where a workload is mounted and run directly from backup while full restoration continues underneath. The consequence for ransomware specifically is that the two requirements stop competing. You need fast access to recent restore points to hit an aggressive RTO, and you need long immutable retention to survive a long detection gap. When object storage spans all three tiers, both come from one architecture rather than two. The scalable backup target architecture covers how this is typically laid out, and the backup target definition covers the terminology. Ransomware recovery readiness checklist Immutability Retention enforced at the storage layer, not by the backup application Compliance mode where the copy must survive a compromised administrator Retention duration set against observed detection gap, not compliance minimum Retention changes logged and alerted, not merely permitted to privileged roles Isolation At least one copy reachable without production identity Repository unreachable from a compromised production network segment Retention policy administered outside the backup server’s reach No single identity with authority over every copy Recovery speed A stated VMs-per-hour figure derived from a timed test, not a vendor datasheet Known concurrency ceiling and a known reason for it Restore order defined by business dependency, not alphabetically Instant recovery validated if the RTO depends on it Validation Restore testing graded across all five levels, on a schedule A clean room environment that exists before it is needed A documented method for identifying the last known good restore point Runbooks written to be executed by someone who did not design the system Frequently asked questions How fast should ransomware recovery be? There is no universal target — the useful question is whether your measured recovery time is shorter than the outage your business can absorb. Express it as workloads restored per hour, derive the total from your actual workload count, and compare that against the tolerance the business has stated. If the two numbers have never been placed side by side, that is the first task. Does immutable storage guarantee ransomware recovery? No. Immutability guarantees a copy exists in the state it was written. It does not guarantee that the state was clean, that you can reach the copy without production credentials, or that you can restore from it fast enough to matter. It is a necessary condition, not a sufficient one. Why is object storage faster for large-scale restores? Because a flat namespace has no directory metadata to serialize on. Restore streams operate independently, so throughput scales with concurrency rather than degrading under it. In a mass recovery — hundreds or thousands of workloads at once — concurrency is the dominant term in the recovery time equation. What is safe copy isolation? Keeping at least one recovery copy reachable through a path that shares no identity, network or control plane with production. The test is whether you could still mount and read a backup on the assumption that every production credential is in hostile hands. How often should restore testing happen? Graded by cost and disruption: object verification continuously, single-workload restores weekly, application-consistent restores monthly, timed mass parallel restores quarterly and a full isolated recovery annually. The quarterly test is the one that produces a VMs-per-hour number you can defend. Recovery is an operation, not a configuration The architectures that recover well are not distinguished by having more protection features enabled. They are distinguished by having measured something. They know their VMs-per-hour figure because they timed it. They know their isolation holds because they tested it with production credentials assumed lost. They know which restore point is clean because they built somewhere to find out. Immutability, isolation, parallelism and validation are four independent properties, and a gap in any one of them makes the other three approximately decorative. Object storage is a good foundation because it supplies enforceable retention and parallel restore in the same system — but the foundation is not the outcome. The outcome is a number you can say out loud. If you cannot state yours today, that is the finding. Everything else follows from fixing it. Scality builds cyber-resilient S3 object storage designed for recovery at scale. Explore the architecture or browse the glossary for the terms used in this guide.
