Disk wiping

[Curious.George]

I'm just finishing up the design of a "disk maintenance station" to process drives in large batches (high throughputs).

Among other things, it can be used to "sanitize" drives to ensure sensitive information doesn't leak forward. I process 60 drives at a time (hot-swap allowing completed/failed drives to be removed from the fixture without impacting the progress of the other drives). This gets the effective "time per drive" down to just a few minutes -- instead of an hour or more (for TB drives)

[Presently, I only do SATA/SAS drives as there is little demand to process SCSI, FC-AL, etc. -- they just go directly to the shredder]

In addition to (and to some extent, PRIOR to) overwriting the entire volume, I perform some checks (queries) to see if the drive can be completely overwritten and mark it for physical destruction if the process fails to complete as intended.

In most cases, this is also the only actual "test" of the drive's functionality; I monitor write failures, write rate, retries, etc. and mark the drive as failed if these aren't as expected.

[I can also exhaustively test drives -- but usually don't need/want to do this unless the drive is REALLY "precious"!]

The goal, here, is that when a disk has completed this process, I can print a label (w/QR code), slap it on the drive and automatically log it into "inventory".

But, different disk technologies (I don't do SSDs) and manufacturers support different hooks so I can't (won't!) optimize my tests to fully exploit the information that I might be able to coerce from the drive through out-of-band methods.

Are there any other things (wrt wiping) that I might want to sense/flag to:

• avoid wiping a drive that is likely not going to complete successfully
• avoid wiping a drive that is likely to "throw fits"
• complete wiping but end up with a drive that will be unreliable

[Topcat]

Re: Disk wiping

SCSI is a distant memory these days....I love them for keeping retro builds period-specific. SAS/SATA would too be all I'd focus on as well, in the real world, it's all you'll encounter. I didn't even think there were any fiber channel setups in existence still. SSD's are fine for consumer level stuff, but I'd never entrust anything critical to one (see my dead SSD thread)....its a good thing there was nothing on that drive I needed.

Furthermore, listening to those 15,000 RPM seagate SAS drives spin up is simply amazing! I remember hearing my first 10k spin up....15k is just awesome, even the quieter 2.5" versions!

Lets see some pics of this contraption!

[Curious.George]

Re: Disk wiping

SCSI is a distant memory these days....I love them for keeping retro builds period-specific.

There was a time when many of my machines were SCSI -- various flavors. (Sun workstations). I only have one "pure SCSI" left (a "Voyager") but it takes a 2" drive.

SAS/SATA would too be all I'd focus on as well, in the real world, it's all you'll encounter.

Yes. The machine isn't for me (I rarely have a need to wipe that many drives -- though I'll be doing 22 500G SATA drives, today).

And, 3.5" drives are becoming less of an issue -- more interest in smaller laptop drives (I wipe those *in* the laptop so you don't have to dick around with all sorts of different drive caddies, microscrews to hold access panels in place, etc.)

I didn't even think there were any fiber channel setups in existence still.

I use them in my Sun Blade 2000:

bigger/heavier than many servers!

SSD's are fine for consumer level stuff, but I'd never entrust anything critical to one (see my dead SSD thread)....its a good thing there was nothing on that drive I needed.

As my goal, here, is to protect (destroy) the data that may be present on the drive before reuse, I can't make those guarantees with solid state media as it remaps sectors by design. So, SSDs just get shredded.

Lets see some pics of this contraption!

Presently "distributed" on a bench -- I'm waiting to score a rack to mount everything. It's just a set of 5 12-drive (2U) shelfs connected to a small (1U) server. So, eventually, just 10U of rack space (1U of that for a slide-out monitor/keyboard to control it "locally"). Similar to this:



though I use the SC200's as they're 3.5" drives:



[I think I have about 8 of these shelfs so I'll use some of the others for the main server's file store/database store.]

Sadly, because you want constant access to the drives (so you can keep removing "done" drives and feeding new drives into it), you have to leave the pretty bezels off. I know its only a matter of time before they'll get lost... <frown>

[Per Hansson]

Re: Disk wiping

As my goal, here, is to protect (destroy) the data that may be present on the drive before reuse, I can't make those guarantees with solid state media as it remaps sectors by design. So, SSDs just get shredded.

You should use the secure erase ATA command, mechanical HDD's support it too.
This wipes the DCO areas, and any remapped areas (remember mechanical HDD's remap sectors too!)
That way you can erase both mechanical and solid state drives.

[Curious.George]

Re: Disk wiping

You should use the secure erase ATA command, mechanical HDD's support it too.
This wipes the DCO areas, and any remapped areas (remember mechanical HDD's remap sectors too!)
That way you can erase both mechanical and solid state drives.

I looked into that, originally. I discovered many practical problems with it: it's not universally supported; it relies on the manufacturer's idea of what "erased" means; if grabs the disk controller for the duration (i.e., a synchronous operation); some systems (think: laptops) block access to this ATA command (regardless of whether or not the drive supports it); etc.

[There's a fair bit of literature available to document each of these "issues"]

The "safest" (most portable) approach is for me to do as much work in-band as possible to allow personnel to dictate policy -- instead of having the software enforce its notion of policy on the process (e.g. "SECURITY ERASE ENHANCED not supported. Drive has been logged as destined for mechanical destruction")

In-band processing lets the software (at the direction of the Operator) shift resources to suit the needs of the moment. E.g., concentrate on finishing up drives 1-48, ASAP -- at the expense of drives 49-60 -- so at least THOSE drives complete before the system is powered down at the end of the day.