Midway through the clone, the counter of 'unreadable sectors' starts climbing and the speed falls to a crawl. This is the moment most rescues are either saved by patience — or killed by someone cancelling to 'try a different setting'.
A bad sector is a tiny area of the disk surface that can no longer be read reliably. A healthy drive hides a few by remapping them; a failing drive grows them faster than it can hide them. During a clone, the tool meets each one face to face. What the errors mean, and how a good rescue handles them, is the difference between a booted server and a box of parts.
When a normal read fails, the drive itself retries — re-reading the spot many times, adjusting the head, hoping the data comes back. That internal struggle is why a clone's speed collapses around damaged areas from, say, 150 MB/s to a few MB/s. The tool is not broken and the clone is not stuck; the drive is fighting for every sector. On a badly damaged drive this can stretch a clone from one hour to most of a day. Knowing that in advance is what stops people cancelling a 90%-complete rescue out of impatience.
The professional approach (used by ddrescue on Linux rescue media and by the rescue or ignore-errors modes in cloning tools) flips the natural order:
The logic is simple: get 99% of the server safely onto the new drive before spending hours grinding on the 1% that may never come back. If the drive dies during the retries, you still hold a nearly complete, bootable copy instead of nothing.
Each lost sector takes a 512-byte or 4 KB slice out of whatever file owned it. A lost sector inside a text file costs a few characters; inside a database or a virtual disk it can make the whole file unusable. Files that never touched the damaged areas copy perfectly — which on most drives is the overwhelming majority. After the clone, test the important things deliberately: open the accounts database, the shared documents, the mail store. A file that refuses to open was damaged on the old drive before you started; no clone setting could have saved it.
Retries are worth it on a quiet, spinning drive that is merely weak. They are harmful on a drive that is clicking, clunking, or vanishing from the BIOS: those sounds mean mechanical damage, and every extra hour of grinding can score the surface and take healthy areas down with it. The honest rules:
Boot the new drive and let Windows check its own consistency: run chkdsk C: /f on the healthy new drive (never as a stress test on the dying one), then sfc /scannow for system files. These repairs belong after the rescue because they assume the hardware underneath can be trusted — which is finally true. Files chkdsk reports as damaged are the honest cost of the old drive's last weeks; restore those from your regular backup if you have one.
Watch the video to see the clone settings used on a genuinely failing server drive and how the errors were handled without losing the server.
▶️ Watch Full VideoUse the middle path: a rescue or ignore-errors mode that skips a bad area after a few tries and returns later. Pure 'retry forever' can park the clone for hours on one dead spot while the rest of the drive — and your downtime window — waits.
Not necessarily. 100% of the readable data was copied; a file sitting on an unreadable sector arrives damaged. That damage happened on the old drive, usually over weeks. Restore that specific file from backup if one exists.
Occasionally a patient second pass with a rescue tool recovers a few more sectors, because a weak spot may read once in fifty tries. Expect small gains, not miracles — and weigh them against the risk of running a dying drive again.