When the “Input/Output Error” message appears
If you work in IT, sooner or later you’ll face this: plugging a hard drive into a machine and getting a dry Input/output error message. At this point, any manual copy attempts using cp or drag-and-drop are futile. The more you try to read, the more the drive head scrapes against damaged areas, turning a “slightly broken” drive into a “completely dead” one in minutes.
I once spent 6 hours trying to rescue 20GB of data from an old server because I used the wrong tool. My biggest mistake was using the standard dd command. The machine kept freezing, while the data remained stuck in the error zones, much like when one needs to diagnose a slow Linux server under heavy load. After that, I realized GNU ddrescue is the tool specifically built for these tough cases.
Why standard copy commands always fail?
Operating systems often try to read an error zone repeatedly before giving up. This causes extremely frustrating system bottlenecks.
- cp command: Stops immediately upon the first error. You’ll only get a few scattered, insignificant files.
- dd command: Even with the
conv=noerrorflag, it still reads sequentially. If it hits a bad sector area about 1GB long,ddcould take all day to crawl through. Meanwhile, the drive head might die completely before even reaching the healthy data behind it.
Comparing dd and ddrescue: The difference is in the algorithm
The table below summarizes why professionals always choose ddrescue:
| Feature | Traditional dd command | GNU ddrescue |
|---|---|---|
| Reading strategy | Sequential from start to finish | Reads good areas first, handles errors later |
| Mapfile (Log) | Not supported | Saves progress to resume anytime |
| Error handling | Overwrites with junk or hangs system | Smart skipping to protect the drive head |
| Speed | Very slow on bad sectors | Highly optimized for failing drives |
A safe 3-stage data recovery process
Core principle: Never work directly on the failing drive. Use ddrescue to create an image on a healthy drive. Then, extract the data from that image file.
Step 1: Install the tool
You need to install the gddrescue package. Note the extra ‘g’ at the start of the package name to avoid confusion with another tool of the same name.
# Ubuntu/Debian
sudo apt update && sudo apt install gddrescue
# CentOS/RHEL/AlmaLinux
sudo yum install ddrescueStep 2: Identify the hard drive
Check the device name using the lsblk command, a basic step in inspecting Linux internals. Suppose the failing drive is /dev/sdb and you are saving the image file to /mnt/backup. Do not mount the partitions of the failing drive. This prevents the OS from writing more data, which could worsen the situation.
Step 3: Execute in-depth recovery
This is the process I typically use to recover over 95% of data in most cases.
Phase 1: Fast scanning (Scraping)
In the first pass, we instruct ddrescue to quickly grab only the cleanest data areas.
sudo ddrescue -f -n /dev/sdb /mnt/backup/disk_image.img /mnt/backup/recovery.log-n: Do not retry error zones, helping the first phase finish quickly.recovery.log: This is the mapfile. If power is lost mid-way, simply rerun the command, and it will resume where it left off.
Phase 2: Retrying minor error zones
Once most of the data is safe, it’s time to go back and tackle the difficult sectors.
sudo ddrescue -f -d -r1 /dev/sdb /mnt/backup/disk_image.img /mnt/backup/recovery.log-d: Direct Disc Access; bypasses the OS cache to increase accuracy.-r1: Retry each error zone exactly once. If the data is extremely valuable, you can increase this to-r3.
Phase 3: Mount and verify
When the process is complete, you will have a disk_image.img file. Try mounting it to extract your files (referencing a Linux filesystem comparison if the partition type is unknown):
sudo mount -o loop,ro /mnt/backup/disk_image.img /mnt/media/recovery_pointPro-tips to avoid permanent data loss
During a recovery case for a dropped laptop, the hard drive had already started making strange noises. My mistake then was forgetting to use a mapfile. When the process reached 70%, the machine suddenly shut down due to a loose cable. I had to restart from scratch, but by then the drive head had overheated and failed completely. The data was lost forever.
Therefore, always use a mapfile. It’s not just a log; it’s insurance for your time. If the drive gets too hot, use a fan to blow directly on it. High temperatures cause bad sectors to spread rapidly. Never put a hard drive in the freezer based on online “hacks.” Condensation will destroy the circuitry in an instant.
Data recovery is a battle of patience. There have been cases where I had to leave a machine running for 48 hours straight to rescue 99.9% of data from a trashed drive. You can then use an Advanced find command to verify the integrity of specific files. But when you see the customer’s family photo folders appear intact, every bit of effort is worth it.
