Securely decommissioning a dedicated server
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.
- Have a look at hdparm:
hdparm --security-erase <PWD> <device> - Check out wipe. You can fetch wipe with
apt-get install wipeand wipe a disk withwipe /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?
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.