Can You Really Fix Bad Sectors On a Hard Drive? The badblocks, SMART, and Drive Firmware Explained

Quick Summary

TL;DR: No, you cannot repair physical bad sectors on a hard disk. Once the disk surface is damaged, the scratch is permanent. Software can only detect the damage or ask the firmware to hide it.

• Can software fix them? No. badblocks, smartctl, and every other tool can only detect or report bad sectors.
• Can the disk fix itself? Partially. The drive firmware can remap bad sectors to spare ones, but this hides the damage rather than healing it.
• What should you do? If the data matters, clone the disk with ddrescue first, then replace the drive. If it is just a test disk, monitor whether the bad sector count grows.

This guide explains what badblocks, SMART, and drive firmware actually do, using real commands and real disk data.

1. What Are Bad Sectors?

A sector is the smallest unit of storage on a hard disk. Think of it like a single page in a very large notebook. A bad sector is a page that the disk can no longer read from or write to reliably.

When a sector goes bad, any data stored there is at risk. Modern drives have built-in error handling, but once bad sectors start appearing, they are usually a sign that the disk is aging or physically damaged.

Key Point: Bad sectors are not always visible to you immediately. Your operating system may not complain until it tries to read a file stored in a bad location.

2. The Two Types of Bad Sectors

Not all bad sectors are the same. Understanding the difference is the most important part of this guide.

2.1 Soft (Logical) Bad Sectors

These happen when the data in a sector is corrupted, but the physical surface of the disk is fine. Causes include:

• Power loss while the disk was writing data
• Software bugs or malware
• Magnetic signal weakening or confusion

These can sometimes be "fixed" by overwriting the sector with new data. The physical disk is not damaged; only the information on it is wrong.

2.2 Hard (Physical) Bad Sectors

These happen when the actual surface of the disk platter is damaged. Causes include:

• The read/write head touched the platter (a "head crash")
• Dust or contamination inside the sealed drive chamber
• Normal wear and tear over years of use
• Manufacturing defects

No software can heal physical damage. Software can only ask the disk to hide the damage by using spare sectors. The scratch on the platter remains forever.

Critical Warning: If your disk has physical bad sectors, running intense tests repeatedly can actually make the problem worse by stressing already-failing hardware.

3. Our Test Disk: Real Data from a Real Drive

For this guide, we are testing a real 250 GB SATA hard disk. Here is what the system sees before running the test.

3.1 Check the Disk Layout with lsblk

3.1.1 What is lsblk?

lsblk ("list block devices") displays all block storage devices connected to your system: hard disks, SSDs, NVMe drives, and their partitions. It also shows which partitions are mounted and where. This helps you confirm you are targeting the correct disk before running destructive commands.

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 232.9G  0 disk
└─sda1        8:1    0 232.9G  0 part
[...]

Notice that sda is a 232.9 GB disk with one partition (sda1), and it is not mounted. This is safe to test.

If it is mounted, you should unmount it first. It is very important.

3.2 Display Partition Layout and Disk Geometry with fdisk -l

3.2.1 What is fdisk -l?

fdisk is a partition table manipulator for Linux. The -l flag means "list" and tells it to display the partition layout and disk geometry without making any changes. It shows the disk's total size, sector count, sector size, and partition boundaries.

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: 045
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

This confirms the disk has 488,397,168 sectors, each 512 bytes. That is the total surface area badblocks will scan.

4. Use badblocks to Check for Bad Sectors in Linux

4.1 What is badblocks?

badblocks is a Linux utility that tests a storage device for damaged sectors by writing test patterns to every block, reading them back, and comparing what was written with what was read. It is a diagnostic tool, not a repair tool. It tells you which blocks are unreliable, but it does not fix them.

4.2 What Does badblocks -wsv Actually Do?

sudo badblocks -wsv /dev/sda

Let us break it down:

Warning: Destructive Operation: The -w flag erases everything on the target disk. There is no confirmation prompt. It begins writing immediately. Only use this on disks with no important data.

4.3 What the Test Patterns Mean

badblocks -w does not just write zeros. It uses multiple test patterns in sequence:

• 0xaa (binary: 10101010)
• 0x55 (binary: 01010101)
• 0xff (binary: 11111111)
• 0x00 (binary: 00000000)

Each pattern is written to every block, then read back and compared. If the read does not match the write, that block is reported as bad.

4.4 What badblocks Does NOT Do

badblocks does not directly control or perform sector remapping. It does not repair the physical disk surface. Instead, it reads and/or writes sectors and reports I/O errors. When a write operation is performed, however, the drive's own firmware may detect a failing sector and remap it to a spare sector. That remapping is performed by the HDD, not by badblocks.

4.5 The Manual Page Itself Warns Against Using It Directly

Please note that the badblocks manual page explicitly recommends that you not run it directly. Instead, it advises using e2fsck -c or mke2fs -c, which call badblocks internally with the correct block size for your filesystem.

4.6 Why the Manual Discourages Direct Use?

The block numbers badblocks produces depend on the block size. The default is 1024 bytes. If your filesystem uses a different block size (like 4096 bytes) and you do not pass -b, the numbers in your output do not refer to the blocks you think they do. Running the scan through e2fsck -c or mke2fs -c means the block size is correct by construction. The filesystem tools know their own block size; you might not.

4.7 Safe Alternatives to -w When Data Exists

If you need to test a disk that still contains data, use one of these instead:

The -f Flag: badblocks normally refuses to run on a mounted device because it can crash the system or corrupt the filesystem. The -f flag overrides this. The manual's own comment is memorable: "If you think you are smarter than the badblocks program, you almost certainly are not." Unmount the device instead.

5. Reading SMART Data: What the Numbers Mean

Even if badblocks reports no errors, SMART data tells you what the disk's own firmware knows about its health.

5.1 What is smartctl?

smartctl is the command-line interface to the smartmontools package. It reads the SMART (Self-Monitoring, Analysis, and Reporting Technology) data built into virtually every modern hard disk and SSD.

SMART is a health monitoring system inside the drive itself that tracks wear indicators, error counts, temperature, and predictive failure signs. The -a flag tells it to print all available information.

Before running any destructive test, you should always check the disk's built-in health report.

$ sudo smartctl -a /dev/sda
=== START OF INFORMATION SECTION ===
Device Model:     GB0250C8045
Serial Number:    9SF0HF1B
Firmware Version: HPG2
User Capacity:    250,059,350,016 bytes [250 GB]
Rotation Rate:    7200 rpm
...
SMART overall-health self-assessment test result: PASSED
...
Self-test execution status:      ( 121) The previous self-test completed having
                                        the read element of the test failed.

Already we see a contradiction: the disk says "PASSED" overall, but the last self-test failed on a read operation. This is common. SMART overall status can be optimistic while individual tests reveal real problems.

5.2 Running Your Own SMART Self-Tests

You can launch built-in disk self-tests without any destructive operations. These run inside the drive firmware and report their results to SMART.

$ sudo smartctl -t short /dev/sda    # Usually under 10 minutes
$ sudo smartctl -t long /dev/sda     # More thorough, tens of minutes
$ sudo smartctl -l selftest /dev/sda # View results of past tests

The short test checks electrical and mechanical performance plus a sample of read operations. The long test scans the entire surface. Both run in the background; you check results afterward with -l selftest.

5.3 The Most Important SMART Attributes

Backblaze, which operates one of the largest published datasets on drive failure, monitors five SMART attributes for failure prediction. Our test disk reports on most of them:

What 45 Reallocated Sectors Actually Means

This disk already has 45 sectors that the firmware has permanently retired and replaced with spares from its internal reserve pool. Those 45 sectors are physical damage. No software can restore them. The only question now is whether more will appear.

5.4 SMART Error Log Detail

The error log shows repeated read failures at the same location:

Error 24 occurred at disk power-on lifetime: 9578 hours
  Error: UNC at LBA = 0x0018f66b = 1635947
  Commands leading to the error were:
    READ DMA EXT
    READ DMA EXT
    READ DMA EXT
...
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
#1   Short offline       Completed: read failure       90%      9578         1635947

The same Logical Block Address (LBA 1635947) appears in every error. This is a specific location on the disk surface that the drive consistently cannot read. The short offline self-test also failed at this exact location.

5.5 SMART Misses 23% of Failures

Here is the most important caveat about SMART data. Backblaze's published statistics show that 76.7% of failed drives had at least one of the five key attributes above zero, but that means 23.3% of failed drives showed no SMART warning at all. Close to one in four drives fails without ever raising a flag in these statistics.

SMART Is Evidence, Not a Guarantee:

A passing SMART check means nothing bad has been detected yet. It does not mean the drive is healthy, and it is not a substitute for having backups. A clean report is not a clean bill of health. Compare a drive to its own history, not to an internet table.

6. Running the badblocks Test

Now we run the destructive write test. Because this disk has no important data, this is safe.

$ sudo badblocks -wsv /dev/sda
Checking for bad blocks in read-write mode
From block 0 to 244198583
Testing with pattern 0xaa:  20.31% done, 1:55:02 elapsed, (0/0/0 errors)

# After more time passes, you might see errors appear:
Testing with pattern 0xaa:  45.12% done, 4:20:15 elapsed, (3/1/2 errors)

Warning: As we already mentioned, the -w flag will immediately start writing in your disk. Use it when there is no important data in the target disk.

If a disk is already physically degrading, one full destructive write test could push it over the edge and make it stop working entirely. For a test disk, that's acceptable, but it's worth repeating.

6.1 Understanding the Error Counter: (0/0/0)

The three numbers in parentheses at the end of the progress line mean:

Be Patient and Use Power Protection: A full destructive test can take many hours. If power is lost during the test, you may end up with a partially wiped disk and incomplete results. Use a UPS if possible, and keep laptops plugged in. On our 250 GB disk, the test took around 9 hours.

7. What Happens After the Test?

7.1 Scenario A: No Bad Blocks Found

If badblocks completes with zero errors across all patterns, you might see:

Pass completed, 0 bad blocks found. (0/0/0 errors)

This means the disk surface passed the write-read-verify test. However, remember that our test disk already has 45 reallocated sectors in its SMART history. Those were already hidden by the firmware before we started. The test only checks if new problems appear.

7.2 Scenario B: Bad Blocks Are Found

If badblocks finds bad blocks, it will print their block numbers:

1635947
1635948
1635950
Pass completed, 3 bad blocks found. (3/0/3 errors)

Notice that block 1635947 matches the LBA from the SMART error log. This is powerful confirmation: the disk firmware and badblocks are pointing to the same physical location.

7.3 What You Can Do With the Bad Block List

You can save the list to a file and tell the filesystem to avoid those blocks when creating a new filesystem:

7.3.1 What is mkfs.ext4?

mkfs.ext4 creates an ext4 filesystem on a partition. This is the process of formatting a partition so Linux can store files on it. The -l option (lowercase L) tells it to read a list of bad blocks and mark them as unusable in the filesystem's data structures, so your files will never be written to those physical locations.

sudo badblocks -wsv -o badblocks_list.txt /dev/sda
sudo mkfs.ext4 -l badblocks_list.txt /dev/sda1

The -l option tells mkfs.ext4 to mark those blocks as unusable in the filesystem. Your data will never be written there. But remember that this is workaround, not repair.

7.4 Who Actually Does the Remapping?

This is the most misunderstood part of what people call 'disk repair'.

The Truth About Remapping:

When badblocks -w writes to a bad sector, the disk firmware may decide to reallocate it to a spare. But this only happens if the firmware detects a problem during the write operation. badblocks does not command the remap. It simply writes data, and the disk's internal brain decides what to do.

8. What If Your Disk Still Has Data?

This entire guide assumes your disk has no important data, which is the only safe condition for running badblocks -w. If your disk contains files that matter, do not run destructive tests on it. Every read and write operation on a failing drive is a risk.

8.1 The Golden Rule: Image First, Test Second

If the data matters, the order of operations is:

1. Clone the disk to a healthy drive or image file using a tool designed for damaged media
2. Verify the clone and recover files from it
3. Only then run tests on the original (if you still care about its condition)

8.1.1 What is ddrescue?

ddrescue (GNU ddrescue) is a data recovery tool that copies data from one block device to another, designed specifically for failing drives.

Unlike dd, it intelligently skips over bad sectors, retries failed regions, and keeps a mapfile so you can resume interrupted recovery sessions. It reads the easy parts first, then comes back for the damaged areas, minimizing stress on the failing drive.

$ sudo ddrescue -f -n /dev/sda /dev/sdb rescue.mapfile
# -f = force (overwrite output)
# -n = skip scraping phase initially (faster first pass)
# rescue.mapfile = progress log you can resume from

# Then retry the bad sectors more aggressively:
$ sudo ddrescue -d -r3 /dev/sda /dev/sdb rescue.mapfile
# -d = direct disc access (bypass kernel cache)
# -r3 = retry bad sectors up to 3 times

Stop Writing to a Failing Drive:

Every write to a failing drive is a chance to overwrite something recoverable and more work for a mechanism that is already struggling. If the data matters, clone first, investigate second. Running badblocks -w on a drive with precious data is like stress-testing a burning bridge while you are still standing on it.

9. The Verdict: Can You Really Fix Bad Sectors?

The Short Answer is No. You cannot repair bad sectors.

Not with badblocks or smartctl. Not with any software or tool you can run from your computer. Once a sector is physically damaged, it stays damaged forever.

9.1 Soft (Logical) Bad Sectors: "Correctable," Not "Repaired"

If a sector contains corrupted data but the physical surface is fine, overwriting it with new data can make it readable again. But you did not "repair" the sector. You simply wrote new data over the old corrupted data. The sector itself was never physically broken.

9.2 Hard (Physical) Bad Sectors: Permanently Broken

If the physical surface of the disk platter is scratched, contaminated, or damaged, no software can heal that damage. The scratch does not disappear because you ran a command.

What the disk firmware does is hide the damage by swapping the bad sector for a spare one from its internal reserve pool. The damage is still there. You just cannot see it anymore.

9.3 What Software Actually Does vs. What People Think

9.4 What Should You Do If a Hard Disk Has bad Sectors

Once a sector goes bad due to physical damage, it stays bad forever. The best you can do is:

1. Detect it (with badblocks or SMART)
2. Hide it (with firmware remapping or filesystem bad block lists)
3. Replace the disk (before more sectors fail)

If the data matters, clone the disk first with ddrescue, then replace the drive. If the disk is just for testing and has no important data, you can continue using it while monitoring whether the bad sector count grows. But you have not "repaired" anything. You have only managed the symptoms.

10. Common Misconceptions

11. When Should You Replace the Disk?

11.1 Safe to Keep Using (With Caution)

Zero reallocated sectors, zero pending sectors, zero ATA errors, and badblocks passes cleanly. Disk is healthy.

11.2 Monitor Closely

A small number of reallocated sectors (like our 45) that is stable and not increasing. The disk may last years, but do not store critical data on it without backups.

11.3 Replace Immediately

Rapidly increasing reallocated sectors, current pending sectors above zero, repeated ATA errors, clicking sounds, or badblocks finding new bad sectors on every test. The disk is actively failing.

11.4 How to Check If the Count Is Growing

Run smartctl before and after your badblocks test, then compare:

$ sudo smartctl -a /dev/sda | grep -E "Reallocated|Pending|Uncorrectable"
  5 Reallocated_Sector_Ct   ... 45
197 Current_Pending_Sector  ... 0
198 Offline_Uncorrectable   ... 5

If Reallocated_Sector_Ct goes up after badblocks, the firmware found new bad sectors during the test and swapped them. This proves the disk is still degrading.

11.5 One More Thing: Check the Cable

Not all disk errors mean the disk is dying. A non-zero UDMA_CRC_Error_Count (SMART attribute 199) usually indicates a bad SATA cable or loose connection, not a failing drive. Before you discard a disk, try a different cable and port. Our test disk shows zero CRC errors, so the problem is genuinely on the drive.

Recommended Read:

• A Comprehensive Guide To Recover Data In Linux After Accidentally Deleting Your OS

Resources:

• badblocks(8) - Linux manual page
• badblocks - ArchWiki