Secure Data Destruction on Linux: the wipe Command and Its Alternatives

The wipe command securely destroys data on Linux by repeatedly overwriting files or entire block devices with patterns designed to make the original contents unrecoverable. That is its whole job: not deletion, but destruction. Ordinary deletion with rm only removes the filesystem’s reference to the data — the bits stay on the platters or flash cells until something happens to overwrite them, which is exactly what recovery tools exploit.

Why rm doesn’t delete anything

When you rm a file, the filesystem unlinks the directory entry and marks the blocks as free. The data itself is untouched. Tools like photorec or extundelete can walk the raw device and reassemble “deleted” files minutes or months later. The same logic applies at larger scale: reformatting a partition rewrites metadata structures, not the gigabytes of user data behind them.

Secure data destruction, a requirement in decommissioning and compliance workflows, means making the data itself unreadable. On Linux you have three broad strategies: overwrite the data in place, tell the drive’s firmware to erase itself, or destroy the encryption key that made the data readable in the first place.

The wipe command

wipe is a purpose-built overwriting tool. Pointed at a file, it overwrites the file’s blocks multiple times with patterned and random data before unlinking it; pointed at a block device, it overwrites the whole device:

wipe /home/user/payroll.xlsx     # destroy one file
wipe -r /srv/old-project/        # recurse through a directory tree
wipe /dev/sdb                    # overwrite an entire disk

Its multi-pass patterns date from an era when researchers worried that magnetic-force microscopy might recover overwritten bits from older drive technologies. On any drive made this century, a single overwrite pass is considered sufficient — but the exam-relevant point is simpler: wipe exists to securely erase data by overwriting it, in contrast to rm, which merely unlinks it.

wipe is a separate package (not coreutils), so it may need installing via your package manager. Its close cousin shred ships with coreutils and is therefore on essentially every system.

shred and dd: the built-in overwriters

shred overwrites a file or device with random data, defaulting to three passes:

shred -u -v secrets.txt          # overwrite, show progress, then delete (-u)
shred -v -n 1 /dev/sdb           # one random pass over a whole disk

dd isn’t a security tool, but it overwrites devices just as effectively:

dd if=/dev/zero of=/dev/sdb bs=1M status=progress
dd if=/dev/urandom of=/dev/sdb bs=1M status=progress

One caveat applies to all file-level overwriting (wipe and shred alike): on journaling filesystems, copy-on-write filesystems such as Btrfs, or anything with snapshots, the “overwrite” may land on new blocks while the old blocks survive elsewhere. Overwriting a whole block device sidesteps that problem, which is why device-level wipes are the defensible choice at decommission time.

Why overwriting is unreliable on SSDs

Solid-state drives break the core assumption behind wipe, shred, and dd: that writing to logical block N overwrites the physical location where block N lived. Flash controllers use wear leveling — every write goes to a fresh physical cell, and the old cell is only recycled later. SSDs also reserve over-provisioned space (often 7–28% of raw capacity) that the operating system can never address. Overwrite an SSD end to end and stale copies of your data can still sit in remapped and over-provisioned cells, invisible to the OS but readable by forensic tooling that talks to the flash directly.

The answer on SSDs is to make the firmware do the erasing, because only the controller can reach every cell.

Firmware-level erase: hdparm, nvme, and blkdiscard

For SATA drives, the ATA Secure Erase feature is driven with hdparm. You set a temporary security password, then issue the erase:

hdparm --user-master u --security-set-pass p /dev/sdX
hdparm --user-master u --security-erase p /dev/sdX

For NVMe drives, nvme-cli provides both a format with erase semantics and the more thorough sanitize operation:

nvme format /dev/nvme0n1 --ses=1    # user-data erase
nvme format /dev/nvme0n1 --ses=2    # cryptographic erase
nvme sanitize /dev/nvme0n1 --sanact=2   # block-erase sanitize

Cryptographic erase deserves a special mention: self-encrypting drives (and LUKS-encrypted volumes you set up yourself) always store data encrypted, so destroying the key renders everything ciphertext-with-no-key in seconds. For a LUKS volume, erasing the key slots with cryptsetup luksErase achieves the same outcome in software.

blkdiscard /dev/sdX issues a TRIM/discard across the whole device. It’s fast and tells the controller the blocks are dead, but discard is a hint, not a guaranteed erase — treat it as cleanup, not certified destruction.

Method	Best for	How it destroys data	Key caveat
wipe / shred	Files and HDDs	Multi-pass overwrite of blocks	Unreliable on SSDs and CoW/journaling filesystems
dd from /dev/zero or /dev/urandom	Whole HDDs	Single-pass full-device overwrite	Same SSD limitation; no verification built in
hdparm ATA Secure Erase	SATA HDDs/SSDs	Firmware erases all cells, including reserved areas	Drive must not be frozen; password step required
nvme format / nvme sanitize	NVMe SSDs	Firmware user-data, block, or crypto erase	Needs nvme-cli; sanitize is irreversible once started
Cryptographic erase (SED/LUKS)	Encrypted drives	Destroys the key, leaving unreadable ciphertext	Only as strong as the encryption already in place

Whatever method you use on a drive you intend to reuse, verify and repartition afterward — see gdisk and sgdisk for GPT partitioning for rebuilding the disk, and check the drive’s condition first with smartctl since a failing disk belongs in a shredder, not a reuse pile.

How the XK0-006 exam tests this

• Purpose identification: a question names wipe and asks what it fundamentally does — the discriminator is secure overwrite-based destruction versus plain deletion, moving, or compressing.
• Tool-to-media matching: a scenario decommissions SSDs and asks why shred-style overwriting is insufficient (wear leveling, over-provisioned cells) and what to use instead (ATA Secure Erase, nvme sanitize, crypto erase).
• rm-recovery scenarios: a “deleted” file turns out to be recoverable and the question asks why, or which command should have been used.
• Compliance framing: asked for the fastest defensible way to sanitize an encrypted or self-encrypting drive, the expected answer is cryptographic erase.

Data destruction lives in the Security domain — the full XK0-006 study guide shows what else that domain covers, and XK0-006 practice questions test whether you can pick the right erase tool for the scenario.

Quick reference

• wipe = secure erase by repeated overwriting; rm = unlink only, data remains recoverable.
• shred -u file overwrites then removes a file; shred -n 1 /dev/sdX overwrites a whole disk.
• dd if=/dev/zero of=/dev/sdX is a serviceable single-pass device wipe on spinning disks.
• One overwrite pass is enough on modern magnetic drives; multi-pass is legacy caution.
• Overwriting cannot be trusted on SSDs — wear leveling and over-provisioning hide old cells.
• SATA firmware erase: hdparm --security-erase; NVMe: nvme format --ses=1|2 or nvme sanitize.
• Cryptographic erase (destroy the key) sanitizes encrypted media in seconds.
• File-level overwrites can silently fail on journaling, CoW, and snapshotting filesystems — wipe the device, not the file, when it matters.