Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm about to terminate my relationship with my hosting provider of many years, but I'd like to securely wipe the box before I do. This is a dedicated server running Debian on a single EXT3 drive and although I have root access, I can't boot alternate media since it's headless in a rack somewhere.

I don't need multiple passes, but I would like to wipe free space if possible. Basically I'd like to walk away and make sure I don't leave any of my personal data behind. I'm worried that the box might crash before it finishes wiping/syncing the filesystem if I just run srm -R -s /

share|improve this question
imho, use the dd (at the bottom) – Some Linux Nerd Apr 1 '15 at 0:19
up vote 5 down vote accepted

I have successfully gotten all the way through rm -rf --no-preserve-root / without the system crashing first, and without anything being left on the drive.

share|improve this answer
I ran srm on my data directories, then rm -rf --no-preserve-root / via SSH to cleanup the rest. It threw a couple errors in /dev ands then completed; I didn't quite know what to do at the bash prompt. Without a /bin/ls or /sbin/shutdown, I couldn't confirm success. Twas anticlimactic; I was mentally prepared for it to crash, not a zombie kernel and sshd session. – notpeter Jul 23 '10 at 7:07
This is not secure. The data is not wiped and undeletion is still possible. Better to dd over the disk instead. – qris Mar 31 '15 at 13:37

The ATA protocol has a "secure erase" command, which, as its name indicates, should securely wipe the entire HDD.

See the Kernel wiki article for details, but mind the warnings at the top:

share|improve this answer

You can just use dd to overwrite the whole partition/disk on a running server without any worries. We use it at work a lot (when customer doesn't want to pay for secure physical disk destroy).

You actually wipe the data without mounted filesystem knowing it, so filesystem will begin to freak out as its metadata are being lost, then OS itself will begin to "collapse". However what is already in cache still works. So you can monitor the progress via remote console or KVM (didn't try it via ssh). System is kept running even after dd is finished, however no command will work and all daemons are probably already dead.

I use these commands: dd if=/dev/zero of=/dev/sda bs=1M & and then kill -HUP %1 to monitor the progress (dd will print out current speed and amount of data written). Setting block-size (bs) is very important for achieving the HDD seq write speed with dd.

Each time dd was able to wipe the disk to its end and I was able to issue the kill command (shell built-in) until the end. If you have software raid, you can wipe either the md device itself, or each component device individually.

share|improve this answer
My coworker did this and xwindows failed to crash, should be exactly what the requester needs. – Some Linux Nerd Apr 1 '15 at 0:17

Whatever you choose to do, get onto another provider and test it.

Get a similar instance on AWS (or gcloud or ...) and try it there, keeping the disk and then attaching it to another instance as additional storage and scanning it. dd if=sdb | hd

Just about all of your sensitive material should be in


It is the config files with embedded passwords that bother most people. If you know what they are, search the whole filesystem to root them out.

rm will delete files, but a hex editor will still read the disk. So zero afterwards. Have a look at shred. You should have a log of your config files and where they are for DR purposes right ? Don't forget crontab files if you have passwords in those, say.

The CentOS install, or any ramdisk solution is sound. The kernel will be in memory, you need dd and some bin content. But if you reboot in recovery mode you may not have networking or SSH and cut yourself off.

N.B. Kedare has a good idea, and if you are running from ram on your next reboot (ramdisk) this is possible, it is very hard to recover from /dev/zero writes to begin with so it does not really add value unless your life depends upon it ?

share|improve this answer

My solution involves a multi step approach doing some of the above, but also involving a chroot in ram that should allow dd to finish completely clearing the disk.

First delete all of your sensitive data, leaving necessary files for running the operating system. Then do this (not in a script, do it one command at a time):

mkdir /root/tmpfs/
mount -t tmpfs tmpfs /root/tmpfs/
debootstrap --variant=buildd --arch amd64 precise /root/tmpfs/
mkdir /root/tmpfs/mainroot
mount --bind / /root/tmpfs/mainroot
mount --bind /dev /root/tmpfs/dev
chroot /root/tmpfs/

# fill mainroot partition to wipe previously deleted data files
dd if=/dev/zero of=/mainroot/root/bigfile; rm /mainroot/root/bigfile
# now clobber the entire partition, probably won't be able to stay connected to ssh after starting this
# obviously change '/dev/md1' to the device that needs cleared
nohup dd if=/dev/zero of=/dev/md1 >/dev/null 2>&1

That should take care of it!

share|improve this answer

You could try to write random data on your disk like this :

dd if=/dev/urandom of=/dev/sda

Is safer than using /dev/zero because it write random data, but it's also A LOT slower..

share|improve this answer
As someone who doesn't know better, why are people down voting this? Is this not a good practice? – Canadian Luke Mar 30 '15 at 17:07
@CanadianLuke The question is about securely erasing an already running server. You can't write to a mounted drive like this, so it won't work. – longneck Mar 30 '15 at 18:39
@longneck Thanks. For some reason, I thought root could do that... Although I've never tried, so I'll take your word for it. Thanks for explaining though – Canadian Luke Mar 30 '15 at 18:40
@longneck ya you can, added the comment above but i had a really paranoid coworker do that. Actually you can completely unplug your hard drive and linux will still keep on running everything in memory without anything more than a bunch of application error messages. – Some Linux Nerd Apr 1 '15 at 0:17

Before you destroy the OS you could remove anything sensitive and zerofill (using dd if=/dev/zero of=justabigfile).

And I believe most systems will survive a dd to a running system long enough to overwrite the entire disk. There is no way back if it doesn't, of course.

share|improve this answer
If you delete all of the files you are concerned about before you do this, swapoff your swap partition, wipe the swap partition (using wipe or dd), then the above should be pretty safe. You'll need to do it as root to get past the 5% reserved for root, and you might not wipe all of the filenames, but the data should be gone. – Slartibartfast Jul 12 '10 at 1:20

The CentOS installer (anaconda) that ships with the PXE images includes a VNC server, so you can alter your grub config to boot the CentOS installer, passing the answers to the pre-stage 2 installer questions on the grub line, reboot and then VNC to the installer.

Now, if my memory serves me correctly, from within that installer you should be able to drop to a shell, from which you can access and destroy the disk.

Copy the vmlinuz and initrd files from the PXE dir in the CentOS distro ( to /boot and modify your grub config:

default 0
timeout 5
title CentOS
root (hd0,0)
kernel /boot/vmlinuz.cent.pxe vnc vncpassword=PASSWORD headless ip=IP netmask= gateway=GATEWAYIP dns= ksdevice=eth0 method= lang=en_US keymap=us
initrd /boot/initrd.img.cent.pxe

Incidentally, any decent hosting company should be prepared to destroy your disks for you.

share|improve this answer
They aren't a 'decent hosting company' hence my need to leave and wipe my disks. – notpeter Jul 12 '10 at 2:54
I didn't use this method, but using GRUB to boot a minimal rescue image that's preconfigured to enable vnc (or even just SSH) is totally doable. If you mess up, you're potentially left with a system that requires manual intervention to boot properly again, so probably worth testing in a VM first. – notpeter Jul 19 '10 at 19:49
A word on the order in which things are wiped could be useful. By first wiping all partitions except the one containing /boot, you'd be able to start over in case the machine got rebooted in the middle of the process. If /boot happens to be on the / partition, one can delete all files outside of /boot and wipe the free space before finally wiping the entire partition. This would minimize the amount of data left on the disk in case it got rebooted once you had wiped so much, that you would no longer be able to boot it. – kasperd Mar 29 '15 at 9:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.