Selfhosted

Dd. It writes on disk at a block level and doesn't care if there's any kind of filesystem or raid configuration in place, it just writes zeroes (or whatever you ask it to write) to drive and that's it. Depending on how tight your tin foil hat is, you might want to write couple of runs from /dev/zero and from /dev/urandom to the disk before handing them over, but in general a single full run from /dev/zero to the device makes it pretty much impossible for any Joe Average to get anything out of it.

And if you're concerned that some three-letter agency is interested of your data you can use DBAN which does pretty much the same than dd, but automates the process and (afaik) does some extra magic to completely erase all the data, but in general if you're worried enough about that scenario then I'd suggest using an arc furnace and literally melting the drives into a exciting new alloy.

Wow, was your porn that much questionable?

Just FYI: the often-cited NIST-800 standard no longer recommends/requires more than a single pass of a fixed pattern to clear magnetic media. See https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-88r1.pdf for the full text. In Appendix A "Guidelines for Media Sanitation" it states:

Overwrite media by using organizationally approved software and perform verification on the
overwritten data. The Clear pattern should be at least a single write pass with a fixed data value,
such as all zeros. Multiple write passes or more complex values may optionally be used.

This is the standard that pretty much birthed the "multiple passes" idea, but modern HDD technology has made that essentially unnecessary (unless you are combating nation-state-sponsored attackers, in which case you should be physically destroying anything anyway, preferably using some high-heat method).

Usually, I use shred:

shred -vfz -n 2 /dev/device-name

• -v: verbose mode
• -f: forces the write permissions if missing
• -z: zeroes the disk in the final pass
• -n 2: 2 passes w/ random data

# cat /dev/zero > /dev/your-disk

If you want progress bar, use pv instead of cat.

it's not much use now, but to basically avoid the entire issue just use whole disk encryption the next time. Then it's basically pre-wiped as soon as you "lose" the encryption key. Then simply deleting the partition table will present the disk as empty and there's no chance of recovering any prior content.

dd works fine, you'd use it something like this

dd if=/dev/zero of=/dev/[the drive] status=progress conv=fsync bs=4M

if: input file

of: output file

status=progress: shows progress

conv=fsync: basically does the equivalent of running "sync" after the command, makes sure all the kernel buffers have actually written out and are on the device. This causes the command to "hang" near the end depending on how much RAM is installed on the computer. It's not actually hanging it's just finishing writing out the data that's still cached in RAM. This can take a while depending on drive speed and quantity of system RAM.

bs=4M sets the block size to something high enough you're not CPU bottlenecked. Not particularly important exactly what the value is, 4M is a good sane default for most things including this full disk operation.

edit: one pass of zeros is enough to protect against all trivial data recovery techniques. If your threat model includes three letter agencies the hammer and drill bit technique is 👍

While this wouldn't work for you now, something to think about is encrypting new drives going forward so that you don't have to worry about erasing/zeroing them, just toss the encryption key and your good to go.

'dd' works, but I prefer 'shred'. It does a DoD multi-pass shred by default, so I usually use 'shred -vn1z /dev/(drive)'. That gives output, does a one-pass random write followed by one-pass zero of the disk. More than that just wastes time, and this kinda thing takes hours on large spinners. I also use 'smartmontools' to run SMART tests against my drives regularly to check their health.

So I run encrypted drives except for the odd thing where it would be a pain in the anoos, but what would... drive... someone to physically destroy the drives?

Literally the only thing I can think of is having massive amounts of illegal data but what would that even be.

I've been using Shred to wipe things at work. I give it seven passes of random, then a pass of zeros. Probably overkill, but everything is going to surplus auctions and some of the data is sensitive.

I have been researching the same question a few days ago and am currently running > badblocks -b 4096 -c 8 -svw /dev/sda on my old NAS drive. It makes a few passes writing the disk full of 0xaa and 0x55 and then reading it back. I have my disk in a USB2.0 SATA adapter on a raspberry pi 3 and it's currently at 70% of pass #2 after 100 hours, so it sure is slow, but I don't mind.

You could also use DBAN to perform the erasure from outside the operating system.

Besides the mentioned tools, you can also just use disk encryption and discard the secret used to unlock it.

l usually just follow this tutorial

https://m.youtube.com/watch?v=MHSY4RdVL40

worked flawless every time