Disk Enclosures
1752789 Members
5920 Online
108789 Solutions
New Discussion

HS* controllers: DILX for wiping/erasing disks--as alternative to 'dd' / HP Data Sanitation service?

 
Joe Ledesma
Frequent Advisor

HS* controllers: DILX for wiping/erasing disks--as alternative to 'dd' / HP Data Sanitation service?

Anyone use the StorageWorks HS* (HSZ50, HSZ70, etc.) controller utility DILX to write fixed bit patterns on disks in order to overwrite data?

wiping/erasing disks:

I've read various posts in Storage and HP-UX forums about using 'dd' to write zeroes and ones and patterns. I understand that it's still possible to recover data even with multiple overwrites. I understand the issues with how much the data is worth to someone else versus how much it will cost me to make it not recoverable and how much it would cost the third party to still recover it.

We've started running the HS* controller system exerciser DILX to write patterns on disks as an alternative to 'dd'.

The original reason for not using 'dd' was that we were disconnecting the arrays from production servers and I didn't want to run 'dd' on the production servers before disconnecting the arrays because of the possiblity of human error in writing the wrong disk and afterwards I didn't want to bother cabling a test server to each array in turn in order to use 'dd'. It seemed better to just do everything in the hardware. (We are also doing a SCSI format at the controller level with HSUTIL.)

* Has any one done this before?

DILX wasn't designed with our use in mind of course. DILX expects to run for a certain number of minutes so we have to run it long enough to make sure that the entire disk has been covered based on the number of blocks that the tool reports to have written. DILX can't be told to just write to an entire disk. Needless to say, this has been a bit cumbersome.

We need to erase the data / wipe several cabinet-fulls of these SBB drives.

I don't need to do this to military spec but since the disks are going to go to surplus in our organization and purchased by somebody by the pallet-load I want to follow due diligence.

Therefore, I did pursue going back to 'dd; in order to use a /dev/random type device rather than a fixed pattern. Since our servers our Tru64 AlphaServers I originally opened this thread in the Tru64 System Administration forum:

wiping disks before disposal/re-sale: dd if=/dev/urandom ?

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=374669

Through testing, I basically found out that /dev/urandom was too CPU intensive to write even one disk in a reasonable amount of time.

So therefore, I fell back to writing a fixed, rather than a random pattern and as long as I was going to write a fixed pattern, I went back to using DILX rather than 'dd'.

Also, it turns out that HP has a service to remove old data: Data Sanitization Service. From this description:

"Using software coded to write multiple copies of deliberate bit patterns, they [HP Services] obliterate all data"

http://www.hp.com/hps/storage/ns_sanitization.html

"deliberate bit patterns" sounds like a fixed pattern and not a random pattern.

Therefore, if this is good enough for HP:

"This process helps eliminate the possibility of interrogation of previously written data - even through the use of advanced forensic instrumentation. The resulting sanitization exceeds stringent industry security standards for the cleansing of electronic data."

then using a fixed pattern should be good enough for me.

* Does anyone have any experience with this service? Should I bother asking my HP Services sales rep how much it would cost?

-----------

We're consolidating on an EVA array and migrating off about 8-9 of the ESA10000s, SW800s, etc. So we have more than just a few disk drives to wipe. I suspect other shops that are consolidating storage may have similar issues with disposing of old disks.

Destruction of the disks was too expensive. Our off-site tape handling vendor will certify destruction of a tape for one dollar per tape but costs per disk were prohibitive.

Joe