Bad Advice
Bad data recovery advice — and what to do instead
“Format the disk.” “Run CHKDSK.” “Try another recovery program.” These suggestions are easy to give when a drive stops opening. They are much less useful when nobody has established what failed or what the proposed fix will change.
If you are trying to recover files, making the disk usable again is only part of the question. A repair can change useful evidence. A recovery scan can repeatedly read unstable media. A successful RAID rebuild can leave the original data-loss problem unresolved.
This section examines seven familiar recommendations: why they sound plausible, what they actually do, when they may be appropriate and how to protect your remaining recovery options. If you have already followed one, each article also explains what information to preserve and which additional actions to avoid.
Start with the advice you were given
“Windows asks to format it, so format it”
The problem: Windows cannot use a volume and offers to create a new file system. That does not mean the previous files are gone. Formatting changes structures that may still be useful for recovery; it can also introduce deallocation behavior on suitable storage.
The better starting point: Cancel the prompt, identify the device and its original storage context, then preserve and examine what remains readable.
Read: Windows asks to format your drive? Do not agree yet →
“Run CHKDSK before trying anything else”
The problem: A file-system repair aims for consistency, which is not the same as extracting every useful file. Repair options can modify the source, while a lengthy sector check is poorly matched to unstable media.
The better starting point: Preserve important data or a suitable image before testing repair on a working copy. Understand which options are observational and which enable changes.
Read: Run CHKDSK first? Preserve your files before repair →
“Try every recovery program until one works”
The problem: Switching software does not resolve failing hardware, missing decryption or an incorrectly reconstructed storage layer. Repeated scans of an unstable original can spend readable access without producing a reusable copy.
The better starting point: Separate source access from file interpretation. Where appropriate, acquire an image and compare recovery methods on that image for a specific reason.
Read: Why scanning a failing drive with every tool is risky →
“Save the recovered files back to the same drive”
The problem: Space marked as free can still hold lost files. New output, temporary files and even the recovery software installer can overwrite content that has not yet been extracted.
The better starting point: Prepare separate healthy storage, verify its physical identity and capacity, and keep source reads separate from output writes.
Read: Never save recovered files back to the source drive →
“Keep restarting the clicking drive”
The problem: A temporary return to detection does not establish that a drive is safe to read. New repetitive clicking with failed access needs a different response from normal activity sounds.
The better starting point: Stop uncontrolled retries, preserve the device and its original hardware, and assess the symptoms before deciding whether further access is appropriate.
Read: A clicking hard drive is not a reason to keep restarting →
“The RAID failed — just rebuild it”
The problem: A rebuild assumes the chosen surviving members are the right source. Stale members, read errors and interrupted rebuilds can undermine that assumption. An online RAID can also have a separate damaged pool or file system.
The better starting point: Preserve member history, identify what is still readable and protect important data before changing the configuration.
Read: RAID failure? Do not start a rebuild without checking →
“Put the hard drive in the freezer”
The problem: Household freezing adds uncontrolled temperature and moisture exposure without diagnosing the original fault. A brief change in symptoms is not evidence of a reliable recovery method.
The better starting point: Keep the device unmodified and use its model, failure history and access symptoms to choose the next step.
Read: Do not put a failing hard drive in the freezer →
What makes a recommendation dangerous?
A tool does not have to be defective for the advice to be wrong. The risk often comes from applying a valid operation to the wrong situation, in the wrong order or without a preserved copy.
Scroll horizontally to see the full table →
| Type of action | What can be put at risk? | The question to ask first |
|---|---|---|
| Formatting, initialization or repair | Surviving partition and file-system evidence, and sometimes file content | What will this write, and what has already been preserved? |
| Repeated scanning, retries or stress tests | Continued access to a device that is already unstable | Is this a file-interpretation problem or a source-access problem? |
| Array rebuild or forced configuration changes | Member contents, metadata and consistency between generations | Which members are authoritative, and why? |
| Freezing, tapping or opening a drive | The device's physical state and remaining recovery options | What fault has actually been established, and how does this action address it? |
Two mistakes are especially common: assuming that “read-only” means harmless to any failing device, and assuming that “completed successfully” means the files are intact. Neither statement is a universal guarantee.
The first decision is about the source
Stable access with a logical problem: A deleted folder, missing partition or damaged file system on an otherwise stable device may be suitable for a software workflow. Preserve the source where feasible, choose tools that understand the actual storage layers, and extract to separate storage.
Unstable access or physical warning signs: Repeated timeouts, disconnections, unexpected capacity, grinding or new repetitive hard clicks require source assessment. A normal scan or generic imaging attempt may be inappropriate. Professional acquisition is one possible route, particularly when the data is irreplaceable.
An accessible degraded array: Protect important readable data while access remains stable and establish the member history. Do not equate a maintenance alert with permission to guess at replacement, import or rebuild procedures.
A verified independent backup: Restoring from it may be preferable to recovering from the damaged source. Check the required files or a representative restore, rather than relying only on the latest “job succeeded” notification.
Already tried a fix? Preserve what happened next
Stop adding unrelated experiments. Record the actions and their order: which volume was formatted, which repair options were used, which disk was replaced, or when the symptoms changed. Keep logs and removed members. Do not power a fragile device merely to gather a screenshot.
Do not erase the files you have already extracted because some of them failed validation. Keep successful output and work on copies when testing repairs. Previous mistakes do not automatically mean everything is unrecoverable, but they change the evidence available for the next attempt.
Use the rest of the catalog
Use Cases to identify the situation you are facing. Use Methods to understand preservation, acquisition, storage reconstruction and result validation in greater depth.
The purpose of questioning a bad recommendation is to choose a better sequence: understand the failure, preserve the recoverable state and verify the files before putting the original storage back into service.