If you have ever had to move a decade of accumulated work off a set of ageing drives, you already know the part nobody warns you about: the bottleneck is almost never where you assume it is.
This is a short write-up of what we measured during an office archive migration, why the numbers mattered, and what we would do differently.
The situation
Roughly 14 TB spread across eleven drives of varying age. A mix of 7200 RPM spinning disks from around 2016, two SATA SSDs, and one NVMe drive that had been added late. The goal was to consolidate everything onto a pair of new drives, verify integrity, and retire the originals.
The obvious question before starting: how long will this take? The obvious answer — total bytes divided by drive speed — was wrong by a factor of four.
Sequential numbers lie to you
Run a standard benchmark on a healthy 7200 RPM drive and you will see sequential reads somewhere around 150–190 MB/s. That figure is real, and it is also almost useless for predicting archive migration time.
The reason is that an archive is not one large file. It is hundreds of thousands of small ones: documents, spreadsheets, email exports, scanned PDFs, CAD revisions with eleven versions each. The relevant number is random read performance at low queue depth, and on a spinning disk that collapses to something in the range of 0.5–1.5 MB/s.
Two orders of magnitude. That is the difference between a migration finishing overnight and a migration running for most of a week.
The practical takeaway: before you plan an archive migration, run the random 4K test, not just the sequential one. The sequential figure tells you what the drive can do. The random figure tells you what it will actually do with your data.
Ageing drives degrade unevenly
Three of the eleven drives came back with sequential reads well below spec — one at 71 MB/s against a rated 160. All three passed SMART checks with no reallocated sectors and no warnings.
This is worth knowing. A drive can be perfectly healthy by every diagnostic measure and still have lost half its throughput to accumulated fragmentation, bad cabling, a degraded SATA link negotiating at a lower speed, or simply a controller that has aged badly.
We found one of ours had renegotiated down to SATA II. A cable swap restored roughly 80% of the missing speed. We would never have looked without the benchmark.
What we learned about the destination
The counterintuitive result was that the destination drive mattered less than expected. Writing to a modern NVMe drive, we saw the same total migration time as writing to a decent SATA SSD, because the source drives were the constraint throughout. The fast destination sat idle waiting for data most of the time.
If your budget is limited, spend it on reading faster — better cabling, a proper HBA instead of onboard SATA, more parallel read streams — before you spend it on a faster target.
The part that had nothing to do with drives
Once the digital archive was consolidated, we still had the physical one: nine filing cabinets of paper that predated the point where anything was born digital. Contracts, signed originals, the compliance records that legally must exist on paper.
We had assumed this was the easy half. It was not. Scanning was slow, indexing was slower, and a meaningful proportion of the documents legally had to be retained as physical originals regardless of whether a digital copy existed. Storing them in the office meant paying central London rent for filing cabinets.
We ended up looking at stackt document storage london for the physical side, which handled retention scheduling and retrieval rather than just floor space. The relevant detail for anyone in the same position is that retrieval matters more than storage cost. Boxes are cheap to store and expensive to search, and the moment you need one specific 2019 contract, the difference between an indexed archive and a stack of unlabelled boxes is measured in days.
Practical checklist
If you are planning something similar:
Benchmark every source drive first. Sequential and random 4K, both. Budget your time using the random figure.
Check SATA link speed on older drives. A drive negotiating at the wrong generation is invisible to health diagnostics and costs you half your throughput.
Verify after copying, not during. Checksum verification on a separate pass is faster than inline verification, because inline verification serialises operations that could otherwise run in parallel.
Deal with the physical archive as a separate project. It has different constraints, different timelines, and different legal requirements. Trying to run both at once means neither gets done properly.
Results table
| Drive type | Sequential read | Random 4K read | Effective archive throughput |
|---|---|---|---|
| 7200 RPM (healthy) | 168 MB/s | 1.1 MB/s | ~14 MB/s |
| 7200 RPM (degraded link) | 71 MB/s | 0.6 MB/s | ~7 MB/s |
| SATA SSD | 512 MB/s | 34 MB/s | ~180 MB/s |
| NVMe | 3,180 MB/s | 61 MB/s | ~310 MB/s |
Effective throughput measured against the actual mixed-file archive, not synthetic data.