Failed Drives and Unreadable Sectors: Sanitization Exceptions

Short answer

Treat a failed drive as an unresolved sanitization case until an appropriate treatment and its result can be supported. A sector that cannot be read is not thereby empty. A tool that skips errors, a device that disappears, or a recovery image that looks blank cannot establish removal of the original information.

Separate failure of the communication path from failure of the medium. If the exact device still supports a qualified internal sanitization operation, assess that supported route and its completion evidence. If the required outcome cannot be established through the interface, retain custody and select an authorized alternative disposition, which may require physical destruction.

Who this is for

This runbook is for authorized ITAD operators, storage administrators and reviewers handling unreadable sectors, interrupted wipe jobs, unrecognized disks and warranty-return decisions. It concerns acceptance and exception handling, not data recovery or hardware repair.

The concrete software example is GNU ddrescue 1.30, dated January 1, 2026. It illustrates why a recovery map and an output image have different meanings from a sanitization record. No recovery or erase invocation is supplied for an unidentified device. Exact drive model, firmware, interface and tool support remain prerequisites for an actual operation.

When to use this

Use this workflow when a sanitization job reports errors, stops before completion, loses the target or cannot reach part of the required scope. Start an exception record as soon as the outcome becomes uncertain; do not wait until a shipment is being assembled.

Record what is known separately from what is inferred. “The application could not open the device” is an observation about access. “The drive is physically failed” is a diagnosis requiring more evidence. “The data is sanitized” is a different conclusion again.

When not to use this

Do not initiate further writes while retention, ownership or the need for an authorized recovery attempt is unresolved. A destructive test can remove a remaining recovery opportunity without producing a valid sanitization result.

Do not open a sealed drive, swap circuit boards or clear storage reservations merely to obtain a green status. Those actions require a separate qualified procedure. If the asset remains an active shared-storage member, coordinate its isolation with the storage owner before further work.

Workflow

1. Freeze the target identity and failed attempt

Preserve the asset identifier, physical label, reported identity, model, firmware, interface, enclosure slot and the tool/version used. Save the selected operation, requested range, start time, final or last-known status, error information and any interruption.

A device node can change after reconnection. Before a retry, reconcile the intended physical asset with the newly reported identity. Never resume against a node solely because it has the same name as before. Keep attempted, completed and accepted outcomes as distinct fields.

If a bulk job contains one failing disk, do not let it inherit the successful status of its neighbors. Link each result to its own physical asset.

2. Classify the access problem without overstating it

Ask whether the failure concerns permissions, controller translation, connectivity, device readiness, an unsupported command or a reported medium error. Follow the installed platform's supported diagnostic path and retain its exact result. A command blocked by a bridge does not establish that the drive lacks the capability, while an unreadable sector does not establish successful overwrite.

Do not turn repeated blind retries into the default procedure. Set a review boundary: what diagnostic evidence is needed, which supported retry is permitted, and when the case moves to another disposition route. Changing cables or hosts also changes the path under examination; record the change and recheck identity.

For SCSI/SAS target and capability questions, use the target, support and completion checklist. For ATA devices, keep state and method constraints explicit.

3. Do not convert a recovery map into an erase certificate

GNU ddrescue is designed to recover readable information first and track unresolved regions in a mapfile. Its recovery operation does not automatically write zeros into the output for unreadable input sectors. Existing output contents can therefore remain relevant when interpreting an image. Its map states describe recovery progress, not accepted sanitization of the input medium.

This creates two distinct questions: what was recovered into the destination, and what remains on the original device? A blank-looking destination region cannot answer the second question. Nor does a mapfile's finished recovery state mean that the source was wiped.

Keep source and destination identities separate. A recovery image, a mapfile and an original drive can all remain within the confidentiality scope. If recovery was authorized, add those artifacts to the copy-disposition plan rather than hiding them inside the wipe record.

4. Evaluate a supported alternative operation

A host read error does not by itself prove that a device-internal sanitization operation will fail, nor does it prove that one will succeed. Establish support and method coverage for the exact model and firmware. Define the terminal evidence and the required handling of failures before execution.

Do not substitute a different action merely because it runs faster or bypasses an error message. Cryptographic erase requires its own encryption and key-lifecycle assessment; deleting a key reference on a host is not the same as demonstrating an accepted device result. A progress bar reaching its end is insufficient if the report also says that required work was skipped.

For a partially completed host overwrite, preserve the unresolved ranges. Do not silently shrink the target to the successfully processed portion. A report of “completed with exceptions” needs a reviewer to decide whether the exceptions prevent the intended release; it must not be relabeled as unconditional success.

5. Make the disposition decision explicit

NIST SP 800-88 Rev. 2, September 2025, identifies inaccessible portions, errors, unsuitable techniques and narrowly defined scope as reasons to question effectiveness. Its verification and validation distinction matters here: inspect the outcome, then decide whether it satisfies the required confidentiality objective.

If the evidence cannot support reuse or release, segregate the drive. Obtain an authorized alternative treatment for its actual media technology and required outcome. Keep the device controlled while awaiting that treatment. Physical destruction requires a qualified process and result evidence; a broken connector or an unreadable interface is not a substitute.

6. Keep warranty and transport decisions separate

A warranty-return authorization is not itself evidence of sanitization. Determine whether the organization may transfer a drive whose data-removal result remains unresolved, and who accepts that decision. Review the actual current service terms and handling route rather than assuming all returns receive the same process.

A dated Seagate product-return paper, TP689.2-1606 from June 2016, describes physical destruction for drives deemed unrepairable or without repair demand. That is a scoped description of a manufacturer's return process, not a guarantee for an individual current shipment or a general rule for another provider. Obtain current case-specific confirmation where needed.

Record custody transfers and the final treatment result under the same asset identity. A courier receipt proves a handoff, not the completion of data destruction.

Verification checklist

• Is the physical asset still matched to the failed attempt and any retry?
• Is the failure category supported by actual diagnostics rather than guessed from an error dialog?
• Are skipped, unreadable and unaddressed regions visible in the record?
• Does the selected alternative method apply to this model, firmware and media type?
• Is final treatment evidence available, including outstanding exceptions?
• Has an authorized reviewer accepted the result for the intended destination?

Verification note: acceptance criteria

No disk was read, recovered, overwritten, sanitized or destroyed for this article. The GNU behavior and dated return-process example were reviewed as documentary evidence. A real case requires observed device identity, diagnostic context, an applicable supported procedure and its terminal result. Unreadability is not a measurement of irrecoverability.

Resale and evidence checklist

Release only assets whose required disposition evidence has been accepted. Keep failed and unresolved assets separate from blank inventory. For a fictional batch of twelve drives with eleven accepted records, one asset remains outstanding even if the bulk job displays a final summary. Maintain restricted records through recycling, destruction or another authorized destination.

What not to publish

Do not publish raw recovery maps containing customer context, recovered data, serials, keys, internal locations or transport arrangements. Use a sanitized process summary publicly and retain attributable evidence for authorized reviewers.

Common mistakes

Avoid interpreting a read failure as an empty sector, accepting skipped errors without review, confusing destination-image contents with source treatment, and forgetting copies created during diagnosis. Do not extrapolate treatment coverage from a short scan of the readable portion of a failing medium.

CliDeck workflow fit

A repeatable exception checklist can keep operator observations, supported next steps and reviewer decisions together. Preserve authoritative tool results alongside any console transcript. This workflow does not claim that CliDeck currently repairs failed drives, implements a particular erase command or certifies physical destruction.

FAQ

Should every unreadable sector cause immediate destruction?

Not automatically. Establish the failure, applicable supported alternatives and the required outcome. If the result cannot be supported, keep the case restricted and obtain an authorized disposition decision.

Does successful data recovery mean sanitization succeeded?

No. Recovery creates or reconstructs information in another location. The original medium and any new copies still need their own disposition scope.

Can a tool's “skip bad sectors” option close the job?

Only an appropriate acceptance decision can close the requested scope. Skipping required regions must remain visible and cannot be treated as proof that those regions were sanitized.

Related guides

See the coverage model and its limits, RAID and snapshot scope, and multi-drive capacity planning.