Disk Recovery

Data loss rarely arrives without warning. A failed drive, an accidental rm, a wrong disk selection during installation,

Data loss rarely arrives without warning. A failed drive, an accidental rm, a wrong disk selection during installation, or corrupted partition metadata can interrupt work in seconds. The damage may be logical, physical, or both—and the right response depends on which one occurred. Recovery is most successful when it begins before the missing data is overwritten.
Most failures fall into several broad categories:

  • Logical damage: Files are deleted, a partition is formatted, an MBR or GPT partition table is damaged, or file-system metadata becomes inconsistent.
  • Physical damage: A drive develops unreadable sectors, a mechanical drive reports mechanical errors, or an SSD begins returning corrupted data.
  • Accidental overwriting: A command such as dd writes to the wrong device, or a new operating system is installed over an existing partition.
  • Encryption or media erasure: Full-disk encryption prevents access without credentials, while TRIM and garbage collection may make deleted data on SSDs unrecoverable even when no visible file system damage exists.

Logical problems are often recoverable with software. Physical failures require extra caution because every additional read can worsen the damage, particularly on mechanically damaged drives.

Contain the Incident

The first priority is to prevent further writes to the affected storage device.

  1. Stop using the disk immediately. Close applications and unmount the affected partition if it is safe to do so.
  2. Do not format, initialize, repair, or “try” the drive repeatedly. File-system repair utilities may make changes that complicate later recovery.
  3. Record the symptoms. Note whether the disk is absent, noisy, unusually slow, or visible but unreadable. This information helps distinguish software issues from hardware failure.
  4. Identify the correct device. On Linux, lsblk -f can display disks, partitions, file systems, and mount points. Device letters may change after rebooting, so confirm model and capacity before running any recovery command.
  5. Protect the output location. Recovery software, disk images, and recovered files must be stored on a different physical drive—not merely another partition on the same disk.

If the data is business-critical, stop here and consult a qualified recovery service when the disk has physical symptoms such as clicking, grinding, repeated spin-up, or rapidly increasing read errors.

Create a Disk Image First

For a mechanically unstable drive, cloning is safer than scanning it directly. A copy preserves the original state and allows all recovery work to continue without putting additional stress on the failed hardware.

GNU ddrescue is useful for this purpose because it can skip unreadable regions and revisit them later:

sudo ddrescue -d /dev/sdb /path/to/disk-image.img /path/to/rescue.log
sudo ddrescue -d -r3 /dev/sdb /path/to/disk-image.img /path/to/rescue.log

The first pass copies readable sectors while recording failures. The second retries problematic areas. The destination image and log file must reside on a separate drive with enough space to hold the source disk.

For a healthy disk with a deleted partition or file, direct scanning may be reasonable. Even then, creating an image first provides valuable insurance against accidental changes.

Recovering Partitions and Deleted Files

TestDisk

TestDisk is an open-source utility for diagnosing disks and rebuilding partition tables. A typical partition-recovery workflow is:

  1. Start the program from a live environment or another system.
  2. Select the correct physical disk.
  3. Choose the appropriate partition-table type, such as Intel/MBR or EFI GPT.
  4. Run Analyse, followed by Quick Search.
  5. Review the detected partitions and verify their boundaries, type, and file system.
  6. Write the table only after confirming that the results match the original layout.

Before writing anything, save the current partition table and make a full disk image whenever possible. An incorrect partition-table interpretation can hide otherwise recoverable data.

PhotoRec

PhotoRec, bundled with TestDisk, recovers files by identifying their internal signatures rather than relying on directory entries. It can be effective when a partition has been formatted or file-system metadata has been damaged.

However, signature-based recovery has limitations:

  • Original file names and folder structures may not be preserved.
  • Fragmented, compressed, encrypted, or sparse files may remain unusable.
  • A large volume can take considerable time to scan.

Recovered files should always be saved to another disk. Writing them back to the source volume can overwrite data that has not yet been recovered.

Windows Recovery Tools

Tools such as Recuva and DiskGenius provide graphical workflows for scanning partitions and recovering deleted files. A general process is:

  1. Select the affected physical disk and partition.
  2. Choose a deep or full scan rather than relying only on the file-system index.
  3. Preview and filter the results.
  4. Copy selected files to a folder on a different drive.

Results should be treated as a form of triage. A file appearing in the list does not guarantee that its contents are complete, so important documents should be opened and verified after recovery.

Repairing File Systems Carefully

Commands such as chkdsk /f on Windows and fsck on Linux can restore a damaged file system to a usable state. They can also modify metadata, move damaged entries, or quarantine files. Use them when the goal is to restore normal system operation, especially after the data has been backed up or imaged.

Avoid running repair tools on a volume containing the only copy of critical files. A partition that will not mount is not necessarily beyond recovery; software can often work directly from an image.

When the Failure Is Physical

Mechanical symptoms—including clicking, scraping, grinding, or a drive that repeatedly disappears from the device list—suggest hardware failure. Repeatedly scanning such a disk may cause damaged heads or platters to lose more data.

Professional recovery may involve transferring the storage medium to a controlled environment and reading it with specialized hardware. Clean-room work is generally reserved for cases involving damaged heads or internal components. Opening a consumer drive outside such conditions can release contamination and permanently destroy the remaining data.

SSD failures present different challenges. Some problems involve worn flash memory, failed controllers, or firmware issues rather than readable bad sectors. Encrypted volumes also require valid credentials or encryption keys; recovery software cannot bypass modern full-disk encryption simply because the operating system no longer boots.

Verify and Restore the Data

Recovery is not complete when files merely appear in a results window. Before considering the incident closed:

  • Open representative documents, photos, archives, and database files.
  • Compare recovered data with expected file sizes and timestamps.
  • Check whether critical applications and databases start correctly.
  • Copy recovered data to clean, tested storage.
  • Preserve the original disk and image until the restored data has been verified.

If a copy of the data exists in cloud synchronization, email, virtualization, or backup systems, check those sources before attempting invasive procedures. Sometimes the safest recovery path is restoring a known-good version rather than reconstructing every missing file.

Build Prevention Into the Workflow

Recovery should be the final response to failure, not the primary data-protection strategy. The 3-2-1 backup rule remains a strong foundation:

  • Keep three copies of important data.
  • Use two different storage technologies or locations.
  • Keep one copy off-site or offline.

Automated, versioned backups are more useful than occasional manual copies. Database and application backups should also be application-consistent; copying live files alone may produce an archive that cannot be restored. RAID improves availability, but it is not a backup because replicated disks can fail or be overwritten together.

Regular restore tests, immutable backups, and monitoring for drive health warnings turn disk recovery from a desperate last resort into a controlled contingency plan.