Call us — 0191 406 1051
Mon–Fri · 9am–5:30pm · No fix, no fee
Start a free diagnostic →

Data Recovery Case File · Portable Drives · The Migration Is the Test

Moving Everything at Once Is the Heaviest Thing You Can Ask

His enquiry describes a sensible plan defeated by the drive it depends on. Archived client projects that must remain available for the next year: "I'm having issues with working on an external hard drive and also issues moving the files off into a cloud archival area, in order to format the drive. Ideally I need to keep the files, as there are a lot of archived projects on there that clients will need to access." The intention is right and the method is exposing the problem. A bulk migration is the most demanding thing a drive will ever be asked to do, which is why drives so often fail during exactly this operation.

MediaExternal hard drive holding archived client project material — failing during use and during bulk transfer to cloud storage; retention obligation in force
Reported situationDifficulty working from the drive · bulk transfer to cloud archival failing · drive intended to be formatted after migration · archived client projects required to remain accessible for an extended period
Fault classRead failure exposed under sustained transfer load — imaging under timeout control indicated in preference to file-level copying
Equipment usedBulk transfer discontinued · imaged write-blocked under per-sector timeouts with weak regions revisited · transfer sequenced by client and date priority · every delivered file verified by checksum · original retained until verification complete

The decode: why the migration keeps failing, and the order to work in

Why bulk transfer is the hardest load: ordinary use touches a small part of a drive — opening a project, saving a file, browsing a folder. A full migration reads every occupied region, continuously, for hours, with the drive running warm throughout and never entering an idle state. It is the same reason drives so often fail during backups. The migration is not causing the fault; it is the first operation demanding enough to expose it.

Why file-level copying is the wrong tool here: a copy asks for each file, waits, and either succeeds or fails. Where a region reads unreliably, the operation stalls on a file, times out, and either aborts the batch or skips it — and retrying restarts that file from the beginning, hitting the same region again. So the transfer cannot converge, and each attempt spends the drive's remaining margin on the same difficult places.

What works instead: imaging with per-sector timeouts. Each difficult sector gets a strict budget and is deferred rather than allowed to exhaust the drive's internal retries; the healthy expanse is captured at full speed first; and weak regions are revisited on later passes, where sectors that failed several attempts frequently succeed. Files are then extracted from the image, with the failing drive no longer involved.

The order that matters for his obligation: he has clients who will need this material over the next year, which means some of it matters sooner than the rest. Sequencing the capture by client and by date lets the material with the nearest requirement be confirmed first, rather than waiting for a complete migration that may not finish.

The step he must not skip, and it is the one his plan depends on: he intends to format the drive after migrating. Nothing should be formatted until the destination has been verified — not "the transfer reported success", but a checksum comparison confirming every file arrived byte for byte, plus a sample opened. Cloud transfers of large archives fail silently more often than people expect, and a formatted source plus an incomplete archive is the worst outcome available here.

The point about the arrangement itself: a single external drive holding the only copy of client archives with a retention obligation is a business risk rather than a filing choice. The migration is the right instinct, and the destination should be two places rather than one.

On the bench

Bulk transfer was discontinued, since file-level copying restarts each file after a failure and spends the drive's margin repeatedly on the same difficult regions. The drive was imaged write-blocked under per-sector timeouts with weak regions revisited on later passes, and extraction performed from the image with the failing drive no longer involved. Transfer was sequenced by client and date priority against the retention requirement, every delivered file verified by checksum, and the original retained until verification was complete.

The outcome

The drive imaged under timeout control, material delivered in priority order and every file verified before the original was released. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone migrating off a drive that keeps failing: a bulk transfer reads every occupied region continuously for hours, which is the heaviest load a drive ever takes — so the migration is exposing the fault rather than causing it. Stop copying file by file, because each retry restarts on the same bad region. And never format the source until the destination has been verified by checksum.

Drive failing while you try to migrate everything off it

Stop the bulk copy — it can't succeed and each attempt costs you. A migration reads every occupied region of the drive continuously for hours, which is the heaviest load it will ever take, so it's exposing a fault rather than causing one. File-level copying makes it worse: when a region reads unreliably the operation stalls on that file, and retrying restarts it from the beginning and hits the same place again. What works is capturing sector by sector with a strict time budget per sector, taking the healthy majority at speed and returning to the difficult regions on later passes. And whatever happens, don't format the source until you've verified the destination properly — a checksum comparison, not just a transfer that reported success.

Archive drive failing partway through a migration?
Stop copying — call Newcastle Data Recovery on 0191 406 1051; imaged under per-sector timeouts, delivered in client priority order, every file verified by checksum before the original is released.
Request a quote online →

Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.