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).

# 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.

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

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.

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

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 👍

Why don't you just destroy them? All it takes is a screwdriver, some sandpaper, a magnet and maybe a hammer.