SMART & Drive Diagnostic Tools
Diagnostic tools can reveal how a storage device identifies itself, expose health counters and sometimes run built-in tests. For data recovery, the important question is not only what a tool can report, but whether obtaining that report changes the workload or state of the source.
Observation first, testing second
Reading identification data and already-recorded health attributes is different from starting a self-test or scanning every sector. On a healthy drive the distinction may not matter much. On an unstable source, a long test can consume hours of additional reads, trigger repeated retries, heat the device and spend part of its remaining readable lifetime without preserving any user data.
What diagnostic tools can expose
- Device identity: model, serial number, firmware revision, interface and reported capacity.
- SMART / NVMe health information: vendor-defined counters, error logs, temperature, power-on history and media-health indicators.
- Transport information: whether the device is connected directly or through a USB/SATA/NVMe bridge, and whether the bridge passes diagnostic commands through.
- Read behaviour: slow regions, I/O errors, resets and timeouts — but only if a read test is actually performed.
SMART values are evidence, not a diagnosis. A drive can have alarming counters and remain readable, or fail while its health summary still says “PASSED.” See SMART & Drive Health for interpretation rather than tool choice.
Direct connection vs. USB bridges
USB bridges are not always transparent. Some pass ATA SMART or NVMe health commands correctly, some expose only a subset, and some present a generic USB device instead of the underlying drive. If a tool reports no SMART data through USB, that does not prove the drive has no health information. It may only mean that the bridge does not expose it.
Self-tests and surface scans
Short and extended SMART self-tests, vendor “full tests,” read scans and surface verification all make the device do work. A full read scan can be especially counterproductive on a failing drive because it reads the source for diagnosis instead of copying readable sectors to safe storage. If the data matters and the source is unstable, acquisition normally has priority over exhaustive testing.
Destructive diagnostics
Erase, write-verify, refresh, remap, secure erase, sanitize and destructive benchmark functions are not recovery diagnostics. They intentionally write to or deallocate storage and should not be run on a source that still contains wanted data.
A practical recovery-oriented sequence
- Record how the device identifies: model, capacity, interface and whether detection is stable.
- Read existing health/log information if it can be obtained without stressing the source.
- If reads are unstable, stop diagnostic scanning and move to controlled imaging.
- Run deeper tests only on a copy, a non-critical device, or when the purpose of the test clearly outweighs the recovery risk.
For symptom-driven decisions, see Bad Sectors and a Failing Drive, Drive Not Detected or Keeps Disappearing and Drive Shows the Wrong Capacity.