Peter Gutmann - Patron of the Award.
The award's patron, Peter Gutmann, is a New Zealand scientist who, throughout his extensive career, has explored effective data destruction and many other computer science topics, though he is far more knowledgeable about them than about hard drives. Nevertheless, he achieved international fame with his publication "Secure Deletion of Data from Magnetic and Solid-State Memory" and the 35-pass method of data destruction by overwriting, known as the Gutmann method after its creator.
Gutmann's method allows for effective and irreversible data destruction, but it is absurdly redundant. Furthermore, the publication justifying the introduction of Gutmann's algorithm has little to do with the actual operation of hard drives, and the errors contained therein still underlie many myths that persist in the IT community and are uncritically reproduced in various publications. Therefore, Peter Gutmann is the ideal patron for an award for data destruction that is both effective and contrary to technical knowledge.
Gutmann Award Winners.
RAID-6 array.
RAID arrays are groups of disks combined into a single logical unit to speed up data processing, increase resilience to disk failures, or increase the size of available volumes. A RAID-6 array is resistant to the failure of two disks. However, in this particular case, three of the eight failed simultaneously.
The disk failure resulted from a power outage and was electrical in nature. In theory, the problem should have been simple and inexpensive to solve – simply repairing the easiest of the three failed disks would be enough to get the array up and running. Unfortunately, the IT specialist took a different approach. He went to a computer store, purchased three new disks, and rebuilt the array. He didn't anticipate that rebuilding the array with three new disks inserted at once would result in data destruction.
What exactly was the scale of the damage? The customer's attitude was the issue here. He refused to submit the disks for diagnostics without the promise that all data could be recovered. Unfortunately, in this situation, based on the description of the problem, it's clear that not all data can be recovered, and without analyzing the disks' contents, it's unclear whether anything meaningful can be done. Not to mention that, in data recovery, promising anything without performing even basic diagnostics is irresponsible.
In this situation, haste and routine were likely to be to blame. The action taken was clearly bound to cause irreversible damage. There was a lack of initial backup, proper diagnostics of the damaged disks, and efforts aimed at data recovery. Instead, we were focused on booting the array as quickly as possible, which, after inserting disks with foreign, "zeroed" content, was bound to end in disaster.
RAID-0 array.
The client submitted a damaged drive for data recovery. Never mind the details of the damage; in this case, that's secondary. The drive managed to boot, but then a surprise occurred.
During analysis, it turned out that the logical structures addressed data in an address space exceeding the drive's capacity. Yes, twice. This is a clear indication that the drive must have been operating in an array. The dialogue with the client's IT specialist on this topic is so interesting that it deserves to be quoted in its entirety. Almost in its entirety, without any details identifying the client:
"And this drive, hasn't it ever operated in some array?"
"Yes, it was a RAID-0 array."
"So bring me the second drive from that array."
"But the second drive is functional."
"That's good, but I need it to assemble the array."
"I can't."
"Why?"
"Because we're already using this drive for other purposes."
"Come and get this drive."
"But we need to recover the data from it."
"I can't do that without the other drive."
"But we scanned that drive and the data we need wasn't there, so it has to be on this one."
"Come and get this drive."
RAID arrays (except RAID-1) spread data across all drives in so-called stripes. This means that any file larger than the stripe size will be divided into pieces and saved on different drives. Even files smaller than the stripe size can be divided into pieces on different drives. Therefore, data recovery in RAID arrays requires analyzing all drives and assembling them properly so that complete, working files can be copied from them.
Unfortunately, company IT staff and system administrators often don't know the configuration of the arrays they manage. It's quite common for incomplete arrays to arrive. The described case wasn't the only one where healthy drives from an array were overwritten due to being used for other purposes before someone realized they contained data worth recovering. Arrays are also sometimes "enhanced" with additional drives that weren't part of the array. This complicates the analysis somewhat, but fortunately, it's not a critical issue.
It's also common for the actual array parameters, and even its type, to differ from those declared by the customer. An interesting case of a RAID-1 array that ultimately turned out to be a RAID-0 array was described in Security Magazine No. 5(26)/2024. However, this case does not qualify for the Gutmann Award, as the data was recovered practically in its entirety, despite stupid and irresponsible interference by someone who had previously attempted to recover data from this array.
RAID-50 array.
This patient's story requires a broader context. This wasn't a sudden failure that came like a bolt from the blue, but a problem that had been brewing for several months. Unfortunately, during this time, the IT specialists were blind to the disturbing symptoms indicating drive degradation, and after each incident, when the array finally rebooted, they naively believed that the problem had resolved itself and would never return.
However, after several months of such ad hoc resets, the lack of diagnostics finally took its toll, and the array wouldn't reboot. The drive was identified as the culprit, as instead of a green LED, a red one lit up. Yes, the IT specialist's diagnostic skills ended there; he couldn't even correctly read the drive model from the label, but someone had entrusted him with responsibility for a RAID array at a very large technology company.
In this case, organizational issues played a significant role. The client's reluctance to submit the drives for diagnostics and a lack of understanding of both the array's operation and the data recovery process. There's also likely a fear that diagnostics might reveal administrator errors that would be difficult to brush under the rug. Not every organization wants to learn from mistakes. Some prefer to repeat them.
Perhaps in this case, data recovery would still be possible if approached properly, but it's certainly impossible to recover data from a RAID array based on analyzing just one disk. This is especially true since a RAID-50 array should easily withstand a single disk failure, so it's almost certain that there was some hidden surprise that the company's IT staff couldn't identify without outside help. Furthermore, the very idea of taking a single failed disk, inserting it into the array, and seeing what happens without first analyzing the array as a whole is highly dangerous.
Most RAID array types (except RAID-0) are resistant to the failure of at least one disk. This means that if a single disk fails, that disk can be removed from the array, and the array can still function. The array's contents will change, and during this time, the failed disk's contents will become outdated.
Reconnecting such a failed disk containing outdated data to the array carries the risk of corrupting the current data and destabilizing the file system metadata. This is especially true if the array is missing another disk that failed later. Such an action can lead to similar consequences to those experienced in the case of another Gutmann Award winner – the RAID-6 array.
Therefore, in the practice of data recovery from a RAID array, the entire array is analyzed, the aim is to repair and backup the contents of all drives, and only then are decisions made regarding the array's reassembly. Often, in such situations, the failure of the previously failed drive(s) is omitted and the minimum number of drives required to boot the array of a given type is relied upon, selecting only those drives that were operational in the array until its end. Therefore, it would be extremely greedy and irresponsible to agree to recover data from an array with only one drive available.
Gone with the Wind...
Another example of IT negligence. The first drive in the array failed about two weeks before its complete failure. Not only was it not replaced and the array not rebuilt, but it wasn't even powered off, leaving the heads ploughing across the platters like a plow in a field, the effects of which are visible in the photo below:
By the time the IT specialist finally responded, it was too late, and all the discs looked similar to the image above. The same drive models, often from the same production batch, passing through the same distribution chain, and operating under the same operating conditions, often tend to fail in very short succession. Therefore, it's crucial to quickly respond to a drive failure and rebuild the array before another one fails. RAID-6 was introduced precisely because a second drive failed too often, shattering the array before it could rebuild itself after the first one failed.
The risk of nearly simultaneous failure of multiple drives is even greater with SSDs. A critical factor for SSD failure is wear on the SSDs due to write and erase operations, and RAID arrays do this very evenly. Therefore, it's especially important to consider this risk and take appropriate preventative measures, for example, by building the array on different SSDs using different controllers and Flash-NAND chips. This approach will reduce RAID performance and increase the time between disk failures. However, technical solutions will be ineffective if administrators neglect their responsibilities and delay response to failures.
After the reset it started working...
Resetting devices is one of the most popular troubleshooting methods in the IT community. When devices are restarted, they often forget about old errors and begin working properly. However, this repair method can also be a way to win a Gutmann Award.
During a computer restart, the system sometimes detects errors on the disk and begins repairing them. It runs chkdsk, fsck, scandisk, or a similar procedure. A reassuring message about the disk repair in progress appears on the monitor ...
But what's actually happening, and what's actually being repaired? Contrary to popular belief, the disk isn't actually being repaired. The procedures mentioned above can't actually repair the disk. At most, they can slightly clean up the logical structures of the file system and remove errors found in its metadata. Their true purpose isn't to protect the data on the disk, but to restore the logical structures to a state that allows partitions to be mounted.
This is precisely why, after such a "disk repair", objects are often missing, files disappear, and sometimes new ones with strange names appear. This phenomenon is particularly dangerous in virtualized environments. Virtual machine files contain their own internal file systems with their own logical structures.
The logical structures of virtual machine files are distinct from the logical structures of the file system describing them. Therefore, they can be mistakenly identified as inconsistent or erroneous, which can lead to their corruption or deletion. Dynamic resource allocation and the storage of virtual machine files as sparse files are also a risk factor. Interfering with the logical structures of the file system describing a virtual machine file can lead to uncontrolled release of resources, which can then be occupied and destroyed by being overwritten by another virtual machine. Even if damage to the logical structures does not result in overwriting a virtual machine file but merely in its loss, recovering such a file, due to its fragmentation, can be so laborious and time-consuming that it is difficult to imagine its practical implementation.
The TRIM function also poses a threat to the ability to recover files lost by chkdsk or fsck, which in the case of SSDs leads to the rapid physical destruction of deleted data at the logical structure level. The TRIM function is also present in hard drives using Shingled Magnetic Recording (SMR) technology. In these cases, attempting to recover data at a physical address has a greater chance of success, as hard drives do not physically erase data.
Another risk factor is related to the technical condition of the drive, which can deteriorate during chkdsk or fsck operations. SSDs are particularly vulnerable to this, as they wear out due to write and erase operations. A large number of writes performed on a worn SSD in a short period of time can destroy it. Therefore, ignoring symptoms indicating hardware problems, especially drive degradation, is asking for the Gutmann Award.
The IT specialist tried everything.
The patient is an SSD drive from which wedding photos were accidentally deleted. Typically, the type of data is irrelevant to the recovery process. So why does the fact that they were wedding photos matter in this case? More on that later...
The laptop was sent to an IT specialist for data recovery. What did the IT specialist do (and what didn't he do)?
- he didn't even remove the drive; he worked directly on the laptop from which the data had been deleted, booting the operating system;
- he didn't disable the TRIM function;
- he actively used the internet, as evidenced by numerous installers of less-than-worthy data recovery programs and cracks for these programs in the "Downloads" folder;
- he saved the results of his activities, including scan results, directly to the same drive from which the data was lost.
Leonid Brezhnev and Georgy Zhukov were such scoundrels that they were named heroes of the Soviet Union four times over. And in this case, the scale of the foolish errors made in data recovery warrants the awarding of four Gutmann Awards at once. But what was truly critical to the irreversible data loss? In this case, it was most likely the TRIM function, which led to the physical destruction of the data, and further inept efforts by the IT specialist couldn't have made matters worse.
Why was it important in this case that the lost data were wedding photos? The end customer called with a grudge, and many things had to be explained to him. He seemed to understand, and finally asked what he should do in this situation? Those were the days when a well-known polish politician had one marriage annulled and get another. And since nothing could be done technically, the only option was to annul the marriage and remarry.
Formatting the partition.
It's difficult to pinpoint the origins of the idiotic practice of formatting drives before data recovery. Nevertheless, this practice persists, propagated on internet forums with little substantive value, and in the case of the most incompetent companies offering data recovery services, it's part of their procedures not so much for data recovery but for its further thoughtless damage. Nowadays, it's much rarer, but just a dozen or so years ago, disk initialization and formatting were common among officers securing digital evidence. This problem was particularly common with drives containing surveillance footage, whose logical structure wasn't supported by Windows.
Such behavior can hardly be explained by a lack of knowledge or education. Basic logic should suggest that this idea is extremely foolish. However, the popularity of this error requires an explanation as to why it deserves the Gutmann Award.
A fundamental principle in data recovery is protecting the media from any writes. In certain situations, justified by diagnostics and analysis of the logical structures of the file system, this principle may be violated, but this should only apply to conscious and controlled writes aimed at repairing the logical structures. Formatting a partition violates this principle.
During formatting, new metadata describing the empty partition is created. This overwrites the metadata of the old partition, which, although damaged, can be of significant value in the data recovery process. Even if the damaged metadata cannot be repaired, it can still provide a specialist with valuable information about the logical structure of the partition and its contents.
In the case of FAT file systems, formatting destroys the file allocation tables, making difficult, and often practically impossible, to recover fragmented files. Even in the case of damaged file allocation tables, they can still be useful. The fact that we typically have two copies of them usually allows us to assemble a correct file allocation table based on the correct fragments of both damaged copies. Loss of file allocation tables is a common cause of problems with correct video recovery from memory cards.
Similarly, formatting, to a greater or lesser extent, destroys the logical structures and other file systems. In theory, quick formatting should not lead to file corruption, but this is not always the case. File corruption can occur if we format a partition in a different file system or set different partition parameters than the original ones. We also cannot forget about the TRIM function, which, after formatting, allows the operating system to inform the disk about a large area of free space whose contents are no longer accessible in the LBA addressing and may be physically destroyed within a short period of time. For these reasons, formatting the disk from which the data was lost deserves to be honored with the Gutmann Award. The same award goes to the administrators and moderators of online forums who provide online space for "independently thinking", irresponsible users to express "alternative opinions", and who don't even label advice on formatting drives for data recovery as harmful.