How to Securely Wipe a Hard Drive in Linux: shred, dd, hdparm and blkdiscard

Which Linux Command for Which Drive

Step 1: Find the Right Drive (and Only the Right Drive)

Most wiping accidents in Linux are not caused by the wipe command. They are caused by pointing it at the wrong device. Names such as /dev/sda and /dev/sdb are assigned at boot and can change when you plug in a USB stick, so never rely on a name you saw yesterday.

List the drives with their model and serial number:

Check three columns before you go further:

• MODEL and SERIAL tell you which physical drive it is. Match the serial against the label on the drive.
• TRAN shows the connection: sata, nvme or usb.
• ROTA is 1 for a spinning hard drive and 0 for an SSD. It decides which method you use. USB adapters sometimes report it wrongly, so cross-check with the model number.

For an extra check, look at the stable names under /dev/disk/by-id, which include the model and serial:

Then unmount every partition on the target drive. If the drive holds the system you are running, you cannot wipe it from inside that system. Boot from a live USB (Ubuntu, Fedora or any rescue distribution) and run the commands from there.

Step 2a: Wipe a Hard Drive (HDD) with shred

shred is part of GNU coreutils, so it is already installed on almost every distribution. To overwrite a whole hard drive once with random data and then once with zeros:

What the flags do:

• -v prints progress, which matters on a job that can run for hours.
• -n 1 sets one random pass. Without it, shred defaults to three passes.
• -z adds a final pass of zeros, so the drive reads back as empty and is easy to verify.

How many passes do you need?

One. The belief that hard drives need seven or thirty-five passes comes from drive technology of the 1990s. Both NIST SP 800-88 and IEEE 2883 accept a single overwrite pass as the Clear method for modern hard drives, which we explain in NIST Clear vs Purge vs Destroy. Extra passes multiply the time without adding real protection. Some contracts still ask for the three-pass DoD 5220.22-M pattern, and shred -n 3 covers it, but it is not what the current standards require.

How long does shred take?

Overwriting runs at the drive's sequential write speed, usually 120 to 250 MB/s for a desktop hard drive. A rough estimate for one pass:

• 500 GB: about 35 to 70 minutes
• 1 TB: about 1 to 2.5 hours
• 4 TB: about 4.5 to 9 hours

The -z pass adds a second full write, so double those numbers for the command above.

What shred cannot reach

shred only writes to sectors the drive exposes. Two areas can survive an overwrite:

• A Host Protected Area (HPA) or Device Configuration Overlay (DCO) can hide sectors from the operating system. Compare the visible and native sector counts with sudo hdparm -N /dev/sdX. If they differ, part of the drive is hidden.
• Sectors the drive has remapped after errors are taken out of the address space and are never overwritten.

For most personal drives this is acceptable. For drives holding regulated data, it is one of the reasons teams move to tools that detect and remove HPA and DCO areas before wiping.

Step 2b: Wipe a Hard Drive with dd

dd does the same job with fewer safety rails. It is handy when you want to watch throughput or put the wipe in a script:

When dd reaches the end of the drive it stops with No space left on device. That message is expected. It means the whole drive was written.

Use /dev/zero rather than /dev/urandom. Random data is much slower to generate and gives no extra protection on a hard drive. It also makes verification harder, because you can no longer simply check for zeros afterwards.

shred vs dd

Why shred and dd Do Not Work on SSDs

An SSD does not write data where the operating system asks it to. Its controller spreads writes across flash cells for wear levelling, keeps spare over-provisioned blocks the operating system never sees, and moves data around during garbage collection. When you overwrite /dev/sdX on an SSD, old copies of your data can stay in cells the controller has hidden from you.

The shred manual page says as much: it warns that shred relies on the device overwriting data in place, which flash storage does not do. For SSDs you need a command that tells the controller itself to erase everything it manages, including the hidden blocks.

Step 3: Secure Erase a SATA SSD with hdparm

ATA Secure Erase is a command built into the drive's firmware. The controller erases every cell it manages, including over-provisioned space, usually in seconds to a few minutes. hdparm sends that command from Linux. The kernel.org ATA Secure Erase page documents the same procedure.

Check that the drive supports it and is not frozen

Scroll to the Security section. You want to see:

• supported
• not enabled
• not locked
• not frozen
• supported: enhanced erase (if it is listed, use the enhanced command)

The same section shows the drive's own time estimate for SECURITY ERASE UNIT and ENHANCED SECURITY ERASE UNIT.

If the drive says "frozen"

Many BIOS and UEFI firmwares freeze the drive's security features at boot so that malware cannot lock it. The usual workaround is to suspend the machine and wake it again, which resets the drive without the firmware freezing it a second time:

Wake the machine, run sudo hdparm -I /dev/sdX again and check that it now says not frozen. On some desktops, unplugging and replugging the SATA power cable while the system runs does the same thing, but only try that on hardware and ports that support hot-plugging. If you would rather do this from the firmware menu, our guide to wiping an SSD from BIOS covers the vendor menus.

Set a temporary password and run the erase

Secure Erase only runs when a drive password is set. Set a simple temporary one; the erase removes it:

Then run the erase, using the enhanced form if the drive listed it:

If enhanced erase is not supported, use --security-erase instead. Afterwards, run sudo hdparm -I /dev/sdX once more. Security should show not enabled, which confirms the password was cleared along with the data.

If you would rather not run these commands by hand, our secure erase SSD software buyer's guide compares vendor tools, free tools and enterprise erasers.

Step 4: NVMe SSDs Need nvme-cli, Not hdparm

hdparm speaks ATA. NVMe drives use a different command set, so hdparm --security-erase does nothing useful on /dev/nvme0n1. Install nvme-cli and use the drive's Sanitize or Format command instead. We cover the difference between the two, and how to choose, in our guide to NVMe format vs sanitize.

What About blkdiscard?

sudo blkdiscard /dev/sdX tells an SSD that every block is unused. It finishes in seconds, and afterwards the drive often reads back as zeros. That is not the same as erasing it. TRIM only marks blocks as free. The flash cells can keep their old contents until the controller gets round to cleaning them, and a lab reading the chips directly may still recover data. NIST does not list TRIM as a sanitization method.

blkdiscard -s asks for a secure discard, but very few drives support it. Treat blkdiscard as a fast way to prepare an SSD for reuse inside your own organisation, not as a way to sanitize it before it leaves.

Step 5: Verify the Wipe

A wipe you have not checked is a wipe you are assuming. After a zero-fill with shred -z or dd, compare the whole drive against /dev/zero:

If every byte is zero, cmp reports EOF on /dev/sdX followed by the drive's size in bytes. If it prints differ with a byte number, part of the drive was not overwritten.

For a quick look at the raw contents:

A clean, zero-filled drive shows one line of zeros, an asterisk standing in for every identical line, and the final offset.

After an ATA or NVMe secure erase, the drive may return zeros, ones or random-looking data depending on the vendor, so a full zero comparison does not apply. Sample several regions across the drive and confirm that no readable files, partition tables or text remain.

Wiping Single Files Instead of a Whole Drive

shred -u file.txt overwrites a file and then deletes it. It works reasonably well on ext4 with default settings on a hard drive. It is unreliable on Btrfs and other copy-on-write file systems, on volumes with snapshots, on journaled data modes, and on any SSD, because older copies of the blocks are kept elsewhere. If you need to get rid of individual files with confidence, the safer approach is full-disk encryption from day one, so that destroying the key makes old data unreadable. Our secure file erasure guide goes through the options.

When Command-Line Wiping Stops Being Enough

shred, dd and hdparm are good tools for a handful of drives. They start to fall short when:

• You wipe dozens of mixed drives (HDD, SATA SSD, NVMe) and need the right method chosen for each one, every time.
• An auditor, customer or regulator asks for proof. Terminal output is not a record. You need the drive model, serial number, method, result, date and operator, in a form that cannot be quietly edited. See what a certificate of data destruction must include.
• Drives arrive frozen, with hidden HPA or DCO areas, or with remapped sectors that need to be reported.