What is rehydration?
Rehydration is the process of rebuilding data into its original form from deduplicated storage. Deduplication stores each unique block once and replaces repeats with references. Reading the data back means following those references and reassembling every block in order, which takes more work than reading a plain copy.
Why does deduplicated data need rehydration?
Deduplication breaks incoming data into chunks, keeps one copy of each distinct chunk and records, for every backup, a list of the chunks it consists of. After months of backups, the chunks belonging to one restore point are scattered across the storage, wherever each first appeared. A restore has to locate and fetch every one of them. The same applies when a backup is copied to another system that does not share the same deduplication format, such as tape or a different vendor's storage.
How does rehydration affect restore speed?
Writing to deduplicated storage is largely sequential. Reading back is largely random, because consecutive pieces of a file live in different places. On hard drives, random reads are far slower than sequential ones, so restore throughput from a deduplicating system is often well below its backup throughput.
| Operation | Access pattern | Effect |
|---|---|---|
| Backup to deduplicated storage | Mostly sequential writes | Fast, with good data reduction |
| Restore of a recent backup | Random reads across old and new chunks | Slower than the ingest rate |
| Instant recovery or file browse | Heavy random reads while running | May be impractical on some systems |
| Copy to tape or cloud | Full rehydration first | Long copy windows |
When does rehydration become a problem?
It matters most in a large recovery, when many systems are restored at once and each stream competes for the same scattered chunks. A system that restores one virtual machine acceptably may take days for several hundred. It also matters for instant recovery, where a machine runs directly from backup storage. Why deduplicated restores take longer works through the effect on recovery time.
How can the impact be reduced?
Several approaches help. Keeping the most recent restore points on storage that does not need rehydration, with deduplicated storage used for older ones, gives fast restores where they are most likely. Flash-backed systems handle random reads far better than disk. Backup software can also apply its own deduplication and compression at the source and write to storage that serves reads directly, so that a restore fetches data without a separate reassembly step. The measure that settles the question is restore throughput under realistic load.
Frequently asked questions
Is rehydration only an issue on deduplication appliances?
It is most visible there, because data reduction happens in the storage. Any system that stores data as references to shared chunks has to reassemble it on read.
Does rehydration risk data loss?
Not by itself. It is a performance cost. The related risk is that many backups depend on the same stored chunks, so damage to one affects all of them.
How is rehydration speed measured?
By restoring a representative set of systems and recording throughput, ideally several at once to reflect a real recovery.