One of my dedicated hosting CentOS servers hit 12 years. I received an end-of-life notice on it, and I started receiving SMART errors as well. I guess it's time to let it go. But before I do, I'd like to try and securely erase any left-over information, even though the hosting company claims that the drive will be securely disposed of. However, it's never bad to be safe and take some precautions of your own.

I have erased a number of sensitive files using:

shred -uv filename

Is there a way to generally securely "nuke from orbit" the drive while the OS is running?

  • 1
    Can they mail you the drive? Nov 21, 2015 at 21:06
  • 2
    I don't know if it will work for you but many hosting providers ofter some kind of recovery environment. Last time I decomissioned a dedicated server I booted it up in the providers recovery environment and then used dd to write /dev/urandom over the raid array. Nov 21, 2015 at 23:46
  • @Neil: it did cross my mind, and it's a really good option, thanks for suggesting it.
    – Milen
    Nov 22, 2015 at 20:43
  • @Peter: also a good suggestion, they do have a recovery console but for the cloudy servers. They did offer to put in a Linux installation CD for me, and boot it up. I'll have the console, so can drop into shell and run dd from there. Thanks, Peter, another good idea!
    – Milen
    Nov 22, 2015 at 20:46

2 Answers 2


You can run shred directly on the disk's device node from the running system. It'll be unhappy and throw IO errors as the filesystem is still mounted over a disk being filled with random data, but as the shred binary and any libraries it depends on are fully loaded before the process starts, it should be able to withstand everything else collapsing under the IO errors and still complete the erasing procedure.

Note that there's a small chance of sensitive data being written back to the disk after it's been erased as the filesystem is still mounted read/write and the system might be flushing buffers full of confidential data back to the disk. To mitigate this, remount the filesystem as read-only if you can, though I'm pretty sure you can't easily do that from the root filesystem once the system is running. You could either modify your fstab to mount it using the ro option and reboot (but make sure your boot process doesn't mind it and at the very least can get far enough to start an SSH server so you can connect), or from a physical console/out of band management device, start the OS with a custom kernel command line linux /boot/vmlinuz... root=/dev/sdX ro quiet init=/bin/sh that mounts the root filesystem as read-only and starts a bare shell rather than the init process, and from it you should be able to run shred without any data leaks as the FS is now read only.

Note that if you have any swap partitions set up on the device you're erasing, make sure to "unmount" them with swapoff /dev/sdXY (or commenting them in the fstab and rebooting) before erasing the disk to ensure the process can complete without issues. While IO errors aren't fatal to a process already loaded, messing with the swap partition may make the system crash completely before the erasing is completed.

Finally another option is the ATA Secure Erase command :

hdparm --security-set-pass verysecure /dev/sdX
hdparm --security-erase verysecure /dev/sdX

Assuming you trust the drive's manufacturer to implement it correctly, this should be enough, but all of the above regarding data leaks and the swap partition still applies.

If you're really paranoid you could use one method, then reboot on some installation media or recovery environment over the network (most hosting providers have them) and do the second method.

  • Even though Andrew Philips below did provide most of the information that I needed, really loved the idea to start the kerne with a custom OS command, and possibly erase from there (maybe init itself can be the erasing command). Neat!
    – Milen
    Nov 22, 2015 at 15:03
  • Just to mention that I tried the shred /dev/sda approach some years ago, and it did crash the system completely in the middle of the erasure. I think it was a kernel panic. Can't guarantee that there wasn't a swap partition on it though.
    – Hey
    Oct 3, 2016 at 17:53
  • @YdobEmos probably swap was the culprit. I haven't read the kernel's code, but my own attempts were always successful (so far) so I'd say without swap it should be just fine. Oct 3, 2016 at 18:19

EDIT - OP feels original answer isn't up to SE standards. Left it below. Newer answer right here:

Two options for a full disk wipe. The first one takes advantage of disk drive controller secure erase capabilities, but not all drives have the capability and some BIOSes block the command. It's faster than the second option.

  1. Have a look at hdparm: hdparm --security-erase <PWD> <device>
  2. Check out wipe. You can fetch wipe with apt-get install wipe and wipe a disk with wipe /dev/sdb1.

Also, a lot of information here about clearing linux drives including sections on hdparm and wipe.

OLD Answer

Did you hit every part of the drive? What about swap files? What about /tmp directories? What about files that were already deleted? You really need to hit every byte deleted or not still on the drive not currently used by the OS. Then, what about bad sectors that the disk driver isolated automatically? You can no longer reach those, but a drive recovery service might be able to.

I wonder if you write a program that accesses the disk device drivers directly (/dev/disk0 on my machine) and overwrites it from there. It would be a relatively small bit of C code. The program would be read into RAM and run until the disk is wiped. However, the OS will no longer work after that, and definitely not after reboot. So, you only get to do this once.

The most paranoid agencies used to steamroll and now physically shred their disk drives. Sometimes people don't do what they promise they'll do.

How paranoid are you?


This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .