When a drive is failing, the useful question is not which recovery tool is best. It is which one can I install right now, on the system in front of me, before the disk gets worse.
That answer depends on the distribution, and as far as we could tell, nobody publishes it in one place. The dataset below fills that gap, and its script is included so the figures can be re-checked rather than trusted.
What we found
The open dataset below records, for 12 data-recovery tools across three distributions, what the official package APIs returned on 15 August 2026:
| distribution | tools available (of 12) |
|---|---|
| Ubuntu 24.04 "noble" | 12 |
| Fedora rawhide | 9 (+3 not measured, see below) |
| Arch Linux, official repos | 8 |
Eight of the twelve are present on all three. Those eight are the ones to build a procedure on, because they work whichever live system you end up booting: testdisk, foremost, sleuthkit, smartmontools, hdparm, ntfs-3g, gpart, and ddrescue.
The full dataset and the scanning script are published openly: DOI 10.5281/zenodo.21954201, CC BY 4.0.
The naming trap that cost us a wrong result
The first run of the script reported ddrescue as absent from Ubuntu. That is false, and it is worth explaining because it is the mistake everyone makes.
On Debian and Ubuntu, GNU ddrescue is packaged as gddrescue. Worse, a package literally named ddrescue also exists: it is a different, older program. So:
sudo apt install gddrescue # GNU ddrescue, the one you want
sudo apt install ddrescue # a different, older tool
On Fedora and Arch, the package is simply ddrescue. We added an alias table to the script and a column recording the name actually queried, because a rename is not an absence, and a survey that confuses the two is wrong in the direction that flatters it.
What is missing where
Arch official repositories lack safecopy, extundelete, ext4magic and scalpel. All four exist in the AUR, which is user-contributed and outside the scope of this measurement, if you run Arch and want them, they are a git clone away, just not a pacman -S.
Three Fedora queries did not complete (HTTP 400 from the API): safecopy, ext4magic and scalpel. They are recorded in the dataset with an empty availability flag rather than a zero. Not measured is not the same as not packaged, and treating the first as the second is how a survey quietly becomes wrong.
What this does and does not tell you
It tells you which rescue system gives you the widest toolset with one package manager command. On this measurement, Ubuntu, which matters when you are building a live USB in advance, or choosing what to boot on a machine that is already in trouble.
It does not tell you that a packaged tool will recover your data. Availability is about what you can install, not about what will work. A tool applied to the wrong failure mode recovers nothing, and the wrong tool applied first can destroy what was still recoverable.
That order of operations matters more than the toolset: image the device first, then work on the copy. We cover it in the ddrescue cloning guide, and the failure modes themselves in what actually fails on a hard drive.
Reproduce it
The script is MIT, has no dependencies, and queries only public APIs. Re-run it and you get today's state rather than ours, which is the only reason to trust a measurement like this one:
DOI 10.5281/zenodo.21954201 · CC BY 4.0
Recover the data from your hard drive → EaseUS
Free scan · deleted, formatted & lost files · Windows & Mac
