Deduplication is sold on what it does at write time. A nightly backup that would have consumed ten terabytes consumes a fraction of that, because most of the blocks already exist on the target. The cost of that saving is paid later, at restore time, and it is paid at the moment the organization can least afford to wait. Rebuilding a full copy of the data from a store of shared chunks is called rehydration, and it is the reason a restore from a deduplicating target can run far slower than the backup that created it.
Rehydration is not a fault. It is the inverse of the process that made the backup small. Understanding where its time goes is the difference between a recovery time objective that holds and one that was only ever measured on a single file.
A deduplicating target stores data as chunks, each identified by a fingerprint, and stores each unique chunk once. A backup is then a recipe: an ordered list of fingerprints that, read in sequence, reproduce the original data. Writing a backup means checking each incoming chunk against the index and storing only the new ones. Restoring it means reading the recipe and fetching every chunk it names, in order, from wherever each chunk happens to sit on disk.
Those chunks were written at different times, by different backup jobs, often months apart. The first full backup wrote most of them contiguously. Every incremental since then added a few new chunks wherever there was free space. Garbage collection reclaimed space from expired backups and moved surviving chunks around. By the time a restore is needed, the chunks for one virtual machine can be spread across the whole disk pool.
Spinning disks are fast at sequential reads and slow at random ones. A fresh full backup restores close to sequentially. A restore point built from a year of incrementals against the same base reads its chunks from many locations, and each one costs a seek. The effect grows with retention and with the deduplication ratio, since a higher ratio means more of each restore is assembled from older, shared, scattered chunks.
This is why restore speed tests run in the first month after an appliance is installed rarely predict restore speed in year three. The data has not yet aged into the layout that rehydration has to read. Finding the slowest step in a restore usually means measuring against a restore point with a long history behind it, not the newest one.
| Stage | What happens | What makes it slow |
|---|---|---|
| Index lookup | The target resolves each fingerprint in the recipe to a location | An index too large for memory, forcing lookups to disk |
| Chunk reads | Each referenced chunk is read from the disk pool | Fragmentation from long retention and garbage collection |
| Decompression | Compressed chunks are expanded | Controller CPU shared with other jobs on the appliance |
| Reassembly and transfer | Chunks are put back in order and sent to the backup server | Network and protocol overhead on the restore path |
| Concurrent restores | Several machines restore at once | All of the above, competing for the same spindles |
The last row is the one that matters in a ransomware recovery or a site loss. A single machine restore can look acceptable. Forty machines restoring at once, each asking for scattered chunks from the same pool, can bring the appliance to a fraction of its single stream speed.
Instant recovery features, which boot a virtual machine directly from the backup storage, are especially sensitive to rehydration. The machine runs with every read served through the deduplication layer. Some appliance vendors address this with a separate undeduplicated landing zone that holds the most recent backups in native form, so recent restores avoid rehydration entirely. That works well for the newest restore points and does nothing for older ones, and the landing zone consumes capacity the deduplication ratio quoted at purchase may not have counted.
What happens after an instant recovery boots covers why read latency on the backup target sets the experience for users of the recovered machine.
ARTESCA is object storage software used as a backup target. It stores what the backup software writes and does not apply a second layer of target-side deduplication, so a restore reads objects back rather than reassembling them from a global chunk store. Backup software such as Veeam can still compress and deduplicate within its own files, and that processing happens on the backup server side, where the backup application already knows the structure of the data it wrote.
It presents an S3 compatible API, supports S3 Object Lock for immutable retention, and is deployed on servers the customer runs, from roughly 50 TB to 8.5 PB. The trade is explicit: more raw capacity for the same retention than a deduplicating appliance would claim, in return for restore speed that does not degrade as the restore point ages. Why deduplication ratios are results, not specifications covers how to compare the capacity side honestly.
The test that reveals rehydration cost is simple and rarely run. Pick a representative machine with a long backup history. Restore its oldest retained restore point and its newest, back to back, to the same destination, and record the elapsed time of each. Then restore ten machines concurrently from restore points of mixed age. The ratio between the newest and oldest single restore, and the drop from single to concurrent throughput, describe what the recovery plan can actually expect. Repeating the test each year, as retention lengthens, shows whether the recovery time objective is still being met or quietly drifting out of reach.