Most recovery time objectives were written for planned maintenance and single-system failures: one database server dies, one volume is restored from last night's backup. A ransomware event breaks that model. Hundreds or thousands of systems need to be rebuilt at once, all pulling data from the same backup storage. The number that decides how long the business stays down is not how quickly backups completed. It is how fast the backup storage can push data back out.
Backup infrastructure has been optimized for decades around the backup window: ingest as much as possible overnight, store it cheaply, and assume restores are rare and small. Ransomware inverts all three assumptions, and the storage tier that looked economical on the purchase order can stretch recovery from hours into weeks.
This article defines RTO and RPO, separates backup success from restore performance, compares how common backup targets behave under a mass restore, and closes with how to test restores before an incident forces the question.
What are RTO and RPO, and why does ransomware change the RTO calculation?
Recovery time objective (RTO) is the maximum acceptable time between a disruption and the return of a service to operation. Recovery point objective (RPO) is the maximum acceptable data loss measured in time, effectively how old the most recent usable backup may be. RPO is governed by backup frequency. RTO is governed by everything that happens after a failure: detection, decision, provisioning a clean environment, data restore, validation and cutover.
For a single-system failure, the restore step is a modest slice of total RTO; most elapsed time is people and process. After a ransomware detonation the proportions flip. Hundreds of virtual machines, file servers and databases must be rebuilt before any critical process resumes, all from backup storage sized for nightly ingest rather than a full-estate readback. The restore step becomes the long pole, and the RTO in the runbook is no longer achievable.
Why is backup success rate the wrong metric for recovery readiness?
Backup reporting is built around job completion. A dashboard showing 99 percent job success says the data was captured, but nothing about how fast it can be returned. The two properties stress different parts of the system.
- Backup throughput is a sequential write workload spread across a long window, with expensive work (compaction, replication, tiering) deferrable until later.
- Restore throughput is a read workload that arrives all at once, often random in access pattern, with many jobs contending for the same disks, ports and processing capacity.
- Restore concurrency is how many independent streams the target can serve at full speed simultaneously. A target that hits its rated throughput with one stream may not scale when fifty start at once.
An organization can have an excellent backup success rate and a recovery capability that would take weeks to execute. The only way to know is to measure restore performance under mass-recovery conditions.
How do common backup targets behave under a mass restore?
Deduplication appliances and rehydration cost
Deduplication appliances store each unique chunk of data once. On restore the appliance must rehydrate the data: look up every chunk reference, fetch chunks scattered across the disk pool, and reassemble the original stream. Large restores of older data are often slowest, because those chunks are the most fragmented. Processing capacity, not disk bandwidth, becomes the limit, and concurrent restore jobs divide that fixed capacity rather than multiplying it.
Tape and the retrieval sequence
Tape is a low-cost offline medium with a natural air gap and a legitimate role as a last-resort copy. Its weakness in a mass restore is the retrieval sequence: locate the cartridge, mount it, position, stream, then repeat for every cartridge in the set. Drive count caps concurrency, and much of the elapsed time goes to mechanical operations. Tape suits recovery of a known, limited data set, not rebuilding an entire estate against the clock.
Cloud cold tiers and retrieval delay
Archive tiers in public cloud storage are priced for data written once and read rarely. Reading involves a retrieval request, a wait of minutes to many hours depending on the tier, and then a download over the network path to the recovery site. Egress charges apply to every byte retrieved, so a full-estate restore can also generate an unplanned bill. Cold tiers suit a long-retention copy, not the primary source for time-critical recovery.
Scale-out object storage and parallel streams
Software-defined scale-out object storage distributes data across many nodes and disks with no single controller in the read path. When a backup application starts many restore jobs at once, the reads spread across the whole cluster, so aggregate throughput grows with concurrency instead of being divided by it. Objects are erasure coded but directly readable, with no global chunk index to walk and no rehydration step. Object lock immutability adds protection without retrieval delay, since locked objects remain online.
What does restore throughput mean in hours? An illustrative example
Suppose an organization needs to restore 200 TB after a ransomware event, spread across many systems. The figures below are purely illustrative and ignore network limits, backup application overhead and the time to verify and boot restored systems, all of which add to the total. They show only how sensitive the data-movement step is to sustained throughput.
- At a sustained 1 GB/s, 200 TB takes roughly 200,000 seconds, about 56 hours.
- At 5 GB/s, about 40,000 seconds, roughly 11 hours.
- At 20 GB/s, about 10,000 seconds, under 3 hours.
The point is the relationship, not the specific numbers. Restore time scales inversely with sustained read throughput, and the gap between 1 GB/s and 20 GB/s under concurrent load is the gap between an RTO measured in days and one measured in hours. An eight-hour backup window can be perfectly satisfied by a target that would need a week to give the data back.
How do backup targets compare for recovery?
General characteristics of each target class; actual behavior depends on configuration, sizing and the backup application in use.
| Backup target | Restore throughput characteristics | Immutability | Retrieval delay | Cost profile |
|---|---|---|---|---|
| Deduplication appliance | Limited by rehydration processing; degrades with concurrency and fragmentation of older data | Retention lock available on many models | Online, but effective throughput can fall sharply on large restores | High per-unit cost offset by dedupe ratios; scaling means a larger appliance |
| Tape library | Capped by drive count; sequential access with mount and seek overhead per cartridge | Strong when offline or WORM | Minutes to hours per retrieval; grows with cartridge count | Lowest media cost; handling costs for offsite copies |
| Cloud cold tier | Bounded by retrieval option and bandwidth to the recovery site | Object lock or equivalent typically available | Minutes to many hours before data is readable, plus download time | Low storage cost; retrieval and egress fees on every restored byte |
| On-prem scale-out object storage | Aggregate throughput grows with node count and concurrent streams; no rehydration | Object lock immutability with online access | Immediate; data is online at all times | Commodity hardware; capacity and performance scale together by adding nodes |
How should organizations test restores before they need them?
Run restore drills at realistic scale
A recovery capability never exercised at scale is an assumption, not a plan. Restoring one virtual machine each quarter proves the catalog works, not that the storage can sustain a mass restore. Drills should periodically restore a meaningful fraction of the estate concurrently, record the sustained throughput, and compare the projected full-estate restore time against the documented RTO.
Practice clean room recovery
Restoring directly into the production network after ransomware risks reinfection. A clean room is an isolated environment where systems are restored, scanned and validated before reconnection. Drills should include standing up the clean room and measuring end-to-end time, since isolation and scanning add steps a simple restore test never shows.
Verify immutable copies independently
Immutability only helps if the locked copies are complete and restorable. Verification should confirm that retention locks carry the intended duration, that a privileged account cannot shorten or remove them, that the backup application can read the locked copy, and that restored data passes integrity checks. Testing without storage administrator rights confirms a compromised admin account could not have deleted the copy.
Questions to ask about the current backup target
- What sustained read throughput has been measured with many concurrent restore jobs?
- How does restore performance change for backups that are months old?
- What would a full-estate restore cost in retrieval or egress fees?
- Can restore capacity grow without replacing the target?
How Scality ARTESCA supports faster, safer restores
Scality ARTESCA is S3 object storage designed as a backup target. It runs as software on standard servers, distributes data across nodes so concurrent restore streams draw on the whole cluster, and keeps every copy online rather than behind a retrieval queue. Object lock immutability protects backup data during the retention period, and ARTESCA is validated with major backup applications so immutability and restore behavior can be exercised through the tools an organization already uses.
The immutable backup use case describes how object lock fits into a layered backup design, and the cyber resilience use case covers how storage-level protections combine with clean room recovery to shorten the path back to operation.
The practical step is to measure how long a full-estate restore would actually take from the current backup target, and to treat that number, not the backup window, as the real RTO.
