Do you know that deleting a file really doesn't delete the file content on your disk ? In Unix, a file delete (rm) unlinks the inode, but doesn't actually zero-out the data blocks associated with the file. How can you really destroy the contents of a file? What if you're doing a rm -r of hundreds of files? Deleting files on disk-level can be very interesting if you have highly sensitive data on your disks. Many people who are using Unix know GNU shred, but the docs state "that shred relies on a very important assumption: that the filesystem overwrites data in place." This is the traditional way to do things, but many modern filesystem designs [such as Solaris' UFS] do not satisfy this assumption. ZFS is even trickier, as it uses Copy On Write, so overwriting data actually never happens !


I'll present some ways of deleting data on your disks.

1. The safest option for really deleting a file is to remove the hard drive and physically destroy it. While I relish the thought of beating Sun equipment with hammers, actual physical destruction of hardware is not always an option. Your employer may have very specific policies that must be followed.




2. If you have a degausser laying around, you could degauss the disks. In addition to wiping the contents of the platters themselves, degaussing can render the drives unusable by destroying timing tracks, server motors, and spindle
   motors. Spectrumwest.com had some interesting details.
   




3. Low-level formats :
   This approach assumes you want to delete an entire disk drive or at least an entire file system. These could not be used to target specific files while leaving the rest of the file system intact. Definately worth including though: Sun Blueprint scrubbing disks.
   


4. Alternatives :
   Repeatedly format > analyze > [purge
   
   
   Overwrite raw device with something such as:
   dd if=/dev/zero of=/dev/rdsk/c#t#d#s#
   




5. Fill up the file system :
   A safe way of cleaning a drive is to delete all the files/data we wanted destroyed. Then, fill the file system with junk. One problem with this approach is that it assumes we already know ALL of the sensitive files that should be deleted and don't forget one. Unless all of your sensitive data is positively stored in a known area, you risk leaving a file alive by mistake.
   
   
   
   
   a. Remove all files of interest.
   This will leave disk blocks on the free list which may contain some data that you'd rather not see leave your custody.
   
   
   b. AS ROOT, run this on each filesystem where the files from (a) used to live:
   yes > junk
   and let it run until the filesystem is completely full. Why "as root"? Because the last 10% of the actual free space on each filesystem is reserved for root. (See "tunefs".) This allows root user to manipulate the filesystem and recover from some space exhaustion problems -- even when the filesystem appears to be "full" from the viewpoint of end users.
   
   
   c. Of course, "yes > junk" is rather simple-minded and relatively slow - something that did block writes would run a heck of a lot faster. So for example, you might want to use something a notch more sophisticated, along these general lines:
   touch junk
   while (1)
   dd if=/some/big/file/full/of/crud bs=20k >> junk
   end
   
   
   to do 20K writes. This should run considerably faster, and of course you could also do your variant of this with shell, perl, C, python, whatever you wish. The general idea though, is that you want to force the system to allocate every (currently) free block so that you can scribble on it. This should put recovery of the data beyond the ability of most people.