Data erasure

Disk wiping is one of the creepy fun topics. After protecting a servers' data for years, you suddenly get the chance to wipe it forever. 

This is just an extension of keeping it protected though, thats why it's important to make sure nothing falls through the cracks.

A single disk getting out "unwiped" can cause media havoc or legal prosecution for a company. Some places got desparate enough to shred even disks that were still in their original wrap just to make sure no more used disks could get by unnoticed.

How do disks leave your shop:

  1. Theft of computers / robbery (ugly, nasty)
  2. Theft to steal the disk
  3. End-of-life desktops
  4. End-of-life servers
  5. Replacement due to failure
  6. Replacement during upgrade
  7. Lost backups during transportation
  8. Systems forgotten at partner companies
  9. Systems forgotten during office moves
  10. Nobody knows where that thing went

 

Let's first look at a few things to keep in mind, and then at strategies for making the deletion as quick as possible.

Caveats:

  • Make sure the disk sizes are correct, there may be reserved areas that would not be reached
  • Broken disks that can't be wiped need to be erased another way, that means by physical force or magnetism
  • SCSI commands for low level format may not be put through by the device
  • Consider booting another OS that has more options for disk handling
  • Ideally, physical access to the server should be restricted until all disks are wiped
  • Logical access should also be restricted. Audit Logins to the systems-being-erased
  • Storage arrays need their OS media (cache dump, hostnames, zoning info) wiped, too. This may be problematic, due to vendors not supporting this action.
  • Boot disks need to be erased last if you want to erase from running OS
  • Boot CDs are probably not practical in larger setups, unless you make your own
  • Cache should be empty before starting, and no apps running
  • NVRAM caches and logical media (SSD...) may not be 100% erase-able
  • Disks from arrays have different (520) block sectoring since they store extra CRC/ECC info. (hey ZFS fanbois, did you know this was standard since the 90s?) 

    520 byte Ordering and Conversion:

    Such drives can be converted if neccessary, but this needs practice. The procedure can, especially if interrupted, render the disk inaccessible. The data would in that case still be on the platters for people to pick off. If they are very eager to do so.

Strategy:

  • Raid1 is your very helpful friend. If your raid controller / software implementation supports this, make a single Raid1 volume with many copies. Writing to that one device multiplies on the disk level onto all disks, giving you the fastest write rate
  • If that option is not possible, make multiple arrays and seek to cause most write overhead (i.e. a raid6 of 4 disks) and also keep an eye on avoiding bus congestion
  • Find the right commands to query a disk's serial number from the OS, and the corresponding number on the disks sticker. 
  • Have one printable log document per disk that has all of the following info:
    • Source server
    • Slot ID on the server (damn helpful)
    • OS device ID on the server
    • What data used to be on the disk (thats for the log)
    • OS reported device serial number
    • Serial number on the sticker (and who verified it)
    • Confirmation that the wipe completed (not just started)
    • OS reported device serial number after wiping

Only by cross-referencing these you can get a useful audit trail.

If you're interested in a downloadable template document, let me know! (i.e. via the blog at http://deranfangvomende.wordpress.com/ )

 

 

Tools:

DBAN - There is a bootable CD called DBAN which does the basic stuff well and is the first choice for many people.

Diskscrub - nice OSS tool to run from the OS. At least Linux (apt-get) & AIX well supported, different patterns etc. It can write to files, mountpoints or whole disks.

dd - if your requirement is just "wipe it" then a simply overwrite of zeroes might be enough. dd is pretty fast, which is the nicest thing about it.