Data Corruption

Data corruption happens when data is written, stored, or transmitted incorrectly, leaving the data physically present but altered from its intended values. The hallmark of corruption is that the data is still on the storage medium; it just doesn’t match what was written, what’s expected, or what other parts of the system depend on it being.¹ A corrupted JPEG opens to show partial color blocks where image data should be. A corrupted database refuses to start because internal consistency checks fail. A corrupted application file produces error messages instead of running. The bytes are there; they’re just wrong bytes.

Corruption is not the same as data loss

The two terms are often used interchangeably, but they describe different problems with different recovery paths:

Aspect	Data corruption	Data loss
What happened	Bytes still present, but altered	Bytes no longer present
Typical cause	Bad sectors, write interruption, bit rot, RAM errors	Deletion, formatting, drive failure, overwrite
Recovery approach	File repair, filesystem repair, signature recovery from image	Undelete, file carving, partition recovery
Tools that help	Format-specific repair tools, file carvers, backups	Recovery scanners, file carving, partition reconstruction
Recovery success depends on	Severity of alteration, file format redundancy, presence of backup	Whether the data has been overwritten by new writes

Some scenarios involve both. A partially overwritten file is partially lost (the overwritten regions) and partially corrupted (the parts that remain but no longer match the file’s structure). A drive with developing bad sectors may simultaneously cause new writes to be corrupted and old data to be lost as sectors decay. The conceptual distinction matters even when both apply: the question of “is the data still there?” determines which class of recovery tools to reach for.

What “alteration” actually looks like

At the byte level, corruption can be a single-bit flip (one bit changes from 0 to 1 or vice versa), a multi-bit error, a missing chunk (some bytes are zeroed), or wholesale replacement (a region is overwritten with unrelated data). The Percona database team frames this as “corruption is nothing but an improper format or a sequence of data”: the system reading the data expects a specific byte pattern, and what it finds doesn’t match.² The file or structure may still parse partially, may parse but produce wrong results, or may fail to parse at all.

The most consequential distinction in data corruption is whether the system noticed it happened. Detected corruption raises an error; silent corruption does not. The tradeoffs are very different.³

Detected corruption

The operating system, application, or storage subsystem recognizes that the data it received doesn’t match its expected form, and it raises an error. Symptoms include:

• Files that won’t open (“file is corrupted”).
• Applications that crash on startup or when reading specific files.
• Archive checksum failures when extracting ZIP, RAR, or TAR files (CRC errors).
• Database engines refusing to start with integrity-check failures.
• Backup verifications reporting hash mismatches.
• Operating system errors when reading specific sectors.

Detected corruption is the easier scenario in one important sense: you know it happened. You can attempt recovery with full awareness that the data is bad. The harder scenario is when the system doesn’t know.

Silent corruption

Silent (or undetected) corruption is the more dangerous form. Data changes, the system has no idea, and the wrong data is treated as correct. The corruption propagates: backups inherit the bad data, computations using it produce more bad results, and the original problem may be discovered only much later when something else breaks.⁴

Two industry studies illustrate the scale:

• CERN study (2007): CERN ran a six-month experiment writing and reading specific data patterns across approximately 97 petabytes of storage. About 128 megabytes of data became permanently corrupted silently somewhere in the pipeline from network to disk; the corruption was caught only because CERN was specifically looking for it.
• NetApp study: NetApp analyzed 1.5 million hard drives over 41 months. The study identified more than 400,000 silent data corruption events. Notably, more than 30,000 of those events were not detected by the hardware RAID controllers; they were caught only during scheduled scrubbing operations that compared data against parity.

The 2008 Amazon S3 outage is a real-world example of silent corruption causing system-wide problems: AWS later acknowledged that data corruption was the cause of a widespread S3 outage, with the corruption propagating before being detected.⁵ In 2021, both Google and Facebook published findings that faulty processor cores were causing silent computation errors at a rate of several in thousands of cores; corrupted data emerged from CPUs that should have been reliable.

Why silent corruption is hard to fix

Silent corruption defeats most recovery approaches because nothing flags the bad data. Standard practice for protecting against it includes:

• End-to-end checksums in modern filesystems (ZFS and Btrfs verify checksums on every read; corruption is detected when the data is accessed).
• ECC RAM (error-correcting memory catches single-bit flips before they reach storage).
• Periodic scrubbing (RAID systems and filesystems re-read all data periodically and compare against parity or checksums).
• Backup verification (verifying that backup data matches the source via hashes catches corruption in either side).
• Redundant copies (multiple copies on different media allow comparison to detect drift).

Data corruption can affect storage at three distinct layers, each with different symptoms and different recovery approaches. Identifying which layer is corrupted is the first diagnostic step.⁶

Layer	What’s corrupted	Typical symptom	Recovery approach
File content	Bytes within a single file	Specific file won’t open or shows wrong content	Format-specific repair, backup restore, partial recovery
Filesystem metadata	Structures organizing files into directories	Multiple files inaccessible, RAW partition status, drive shows Not Initialized	chkdsk, fsck, TestDisk, signature recovery
Storage medium	Physical sectors or NAND cells failing	I/O errors, bad sectors, degraded performance	Image first, recover from image, replace drive

Layer 1: File content corruption

The most localized form. Bytes within a specific file are wrong, but the filesystem and storage medium are otherwise healthy. Symptoms appear file-by-file: a JPEG showing partial image with magenta blocks where data is missing, a Word document showing garbled characters, a video that plays partially then freezes, a database file that opens but reports specific row inconsistencies. The rest of the drive’s files are unaffected.

Recovery options for file-content corruption:

• Restore from backup if a recent clean copy exists. Always the preferred approach.
• Format-specific repair tools: Microsoft Word’s Open and Repair, photo repair tools for JPEG/PNG, video repair for MP4/MOV, archive repair for ZIP/RAR.
• File-format internal redundancy: some formats (PNG with multiple chunks, MP4 with cross-references) can survive partial corruption and recover the readable parts.
• Recovery software with file repair features: several modern tools include format-aware repair alongside file recovery.
• Shadow copies / Previous Versions on Windows: if enabled, Windows may have a clean version stored locally.

Layer 2: Filesystem metadata corruption

The filesystem is the structure that organizes raw storage into files and directories. When metadata corrupts, multiple files become inaccessible at once even though their content bytes may still be intact on the medium. Symptoms span more than one file: directories showing as empty when they shouldn’t be, drives appearing as RAW partition, drives showing as Not Initialized, files appearing with garbled names, files with zero-byte sizes or wrong dates.

Recovery options for metadata corruption:

• Filesystem repair utilities: chkdsk (NTFS, FAT), fsck (ext, HFS+, APFS), Disk Utility on macOS. These attempt to repair the filesystem in place; sometimes they succeed completely, sometimes partially, sometimes they make things worse.
• TestDisk for partition table reconstruction when the partition itself is the corrupted layer.
• Signature-based file carving when filesystem repair fails. PhotoRec and similar tools extract files by recognizing their content patterns, bypassing the corrupted filesystem entirely.
• Image-first principle: if the corruption affects a drive with valuable data, image the drive before attempting any in-place repair. Repair attempts on the source can convert recoverable corruption into unrecoverable corruption.

Layer 3: Storage medium corruption

The underlying physical or solid-state storage medium is failing. Sectors no longer reliably retain the bits written to them; reads return wrong data, errors, or nothing. This is the layer where corruption shades into hardware failure: at extreme severity, the drive itself becomes unusable.⁷

Recovery options for medium corruption:

• Image with ddrescue immediately. The medium is failing, and every additional read stresses it further. Imaging captures whatever can be read while the drive cooperates.
• Recover from the image using software (EaseUS, R-Studio, Disk Drill, PhotoRec) rather than the original drive.
• Replace the drive; do not return data to a drive showing storage-medium corruption.
• Professional services for drives where imaging at home risks further damage (clicking sounds, severe SMART degradation, drives that disconnect mid-read).

Gillware Data Recovery uses the helpful framework of “hard” versus “soft” corruption: hard corruption is when the data on the medium is genuinely altered (bad sectors actually returning wrong bits); soft corruption is when bad data is a symptom of a fixable hardware problem (a failing read/write head causes apparent corruption that disappears when the head is replaced).⁸ The distinction matters because soft corruption resolves when the underlying hardware issue is fixed, while hard corruption requires direct repair of the affected data regardless of what hardware fixes are applied.

Data corruption has many causes operating at different levels of the system. Understanding the cause helps predict whether the corruption is one-time (preventable in the future) or systematic (likely to recur until the underlying issue is addressed).⁹

Hardware causes

• Bad sectors developing on hard drives. Specific sectors fail to retain their bits or fail to return them correctly on read. Affected files corrupt when their content lands on the failed sectors.
• NAND cell wear-out on SSDs. Flash memory has a finite number of write cycles per cell; cells that exceed their endurance lose data retention.
• RAM errors: single-bit flips from cosmic radiation or faulty memory modules. Wikipedia notes that cosmic rays cause most soft errors in DRAM; a bit changes in memory and the wrong value is then written to disk.
• Failing read/write heads on hard drives. Heads that aren’t tracking correctly read marginal data, returning approximate but incorrect bytes.
• Drive controller PCB issues. The chip translating between drive media and host can introduce errors when degraded.
• Faulty CPU cores. Google and Facebook published findings in 2021 that faulty cores can produce silent computation errors at a rate of several in thousands; corrupted data emerges from processors that should have been reliable.
• Cable and connection issues producing transmission errors during reads and writes.

Software causes

• Filesystem bugs. Even mature filesystems have edge cases; rarely-triggered code paths produce corruption.
• Operating system bugs. Cache management, write buffering, and shutdown sequences are complex; bugs here corrupt data during otherwise routine operations.
• Application bugs. Programs writing data structures incorrectly produce file-format violations that look like corruption.
• Driver bugs. Storage drivers that handle commands incorrectly cause corruption at the host-to-device boundary.
• Firmware bugs. A 2010 study cited on Wikipedia reported that firmware bugs accounted for 5-10% of storage failures across a survey of 39,000 storage systems.

Operational causes

• Power loss during writes. Files in the middle of being saved are left half-written when power dies. Modern filesystems mitigate this with journaling but don’t fully eliminate it.
• Improper unmount of removable media. Cached writes haven’t yet been flushed when the drive is removed; the filesystem on the drive is left in an inconsistent state.
• Sudden shutdowns. Pulling the plug or holding the power button bypasses the orderly write sequence.
• Heat and environmental stress. Drives running near thermal limits exhibit higher error rates; storage media in high-humidity or vibration environments degrades faster.

External and malicious causes

• Malware and ransomware. Some malware deliberately corrupts files; ransomware specifically encrypts files (a particular form of corruption from the user’s perspective).
• Network transmission errors. Files transferred over unreliable networks may arrive with bit errors that aren’t detected without checksum verification.
• Long-term storage decay (bit rot). Bits on long-stored media gradually degrade. Magnetic media slowly demagnetizes; NAND charge dissipates over time; optical media surfaces oxidize. Wikipedia notes the data corruption rate has remained roughly constant in time, while drive capacities have grown enormously, meaning modern large drives experience more total corruption events than older small drives.

Recovery strategy varies substantially based on which layer is corrupted, whether the corruption was detected or silent, and whether clean copies exist somewhere in the system. The right tool for one scenario can make another scenario worse.

For single-file content corruption

The smallest scope and usually the easiest to address:

1. Check for backups first. Cloud backup history, Time Machine, File History, Previous Versions, version control: any clean copy is the simplest recovery.
2. Try format-specific repair tools. Most major file formats have repair tools tailored to their internal structure.
3. Try opening in a different application. Sometimes the original application is strict; alternative software may tolerate the corruption and recover what’s readable.
4. For partial recovery, extract what’s intact. A corrupted MP4 may play the first 30 seconds before failing; specialized extractors can pull out the working portion.

For filesystem-level corruption

Multiple files affected at once, often presenting as RAW partition or directory inconsistencies:

1. Image the drive first if data matters. Filesystem repair tools sometimes worsen damage; an image is your insurance policy.
2. Try filesystem repair against the image, not the source. chkdsk on Windows, fsck on Linux/macOS. If repair fails, the source drive is unchanged.
3. Try TestDisk for partition-level repair. Especially valuable when the partition table or boot sector is the damaged element.
4. Fall back to file carving when filesystem-level recovery fails. PhotoRec, EaseUS, R-Studio, Disk Drill all support this approach.

For storage-medium corruption

The drive itself is failing. Recovery here is racing against further degradation:

1. Stop using the drive immediately. Each additional read stresses the failing medium.
2. Image with ddrescue: sudo ddrescue -d /dev/sdX drive.img drive.mapfile. Multiple passes recover data that the first pass couldn’t read.
3. Run recovery against the image, not the source. Recovery software, file repair, filesystem repair all proceed against drive.img.
4. For severely degraded drives (clicking, persistent I/O errors, drives that disconnect mid-read), professional recovery services with cleanroom capabilities are the right escalation.

For silent corruption

The hardest scenario because the corruption isn’t flagged. Discovery usually happens when something downstream fails. Recovery options are limited:

• Compare against backups. If verified backups exist from before the corruption window, restore the affected data.
• Use redundant copies. RAID systems with parity or mirroring may have a clean copy; ZFS and Btrfs scrubbing can detect and repair corruption automatically.
• Reconstruct from partial information. For databases and structured data, sometimes the corrupted records can be reconstructed from related uncorrupted records.
• Accept partial loss when no clean copy exists. Silent corruption without backups often produces unrecoverable data; the lesson for next time is verified backups and end-to-end checksums.