Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

Error using DBAN when trying to wipe SCSI drives on a Compaq Proliant ML350.

Posted on 2010-09-09
14
Medium Priority
?
7,417 Views
Last Modified: 2012-05-10
I am trying to wipe several SCSI  hard drives, using an older Compaq Proliant ML350. The server was working and decommissioned this week. DBAN has worked in the past on different servers, but now having the following issue.

 The HP SCSI hard drives vary in size from 72 to 300 GB, I have tried some different DBAN versions 1.0.6 thru the newest 2.2.6. I have tried only 1 drive and multiple drives and in differend slots, but keep getting the same error:

DBAN Failed.
The disks have not been wiped.
Error: Disks not found.
DBAN could need a driver for this computer.


I also tried DBAN with a newer known good hard drive, to prove the old drives werent physically bad, but same issue. The server can't see the drives.

Has anyone run into anything like this before?

0
Comment
Question by:NoneProfit
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 4
  • 2
  • +2
14 Comments
 
LVL 4

Expert Comment

by:PcGod718
ID: 33641002
my guess, since the computer is pretty old and dban is a bootdisk, that its a controller/raid/drive issue.

i would hunt down old reliable adaptec 1542 (yea, im that old) plug in the drives on a regular computer and wipe em down that way.  if you're gonna toss the drives, just get a hex tip driver, open them up and expose them to that sweet sweet air.. and then scratch em up.  kick em, let your friends throw them off buildings.. :)

you could also use something like Diskwipe, spinrite, and my old favortie BCWipe.
0
 
LVL 12

Expert Comment

by:mccracky
ID: 33641064
DBAN doesn't have the drivers for the Hard disk controller of that compaq server, so it can't see the drives.  You can try another Linux live CD and use the utility "shred" or "wipe" or just dd (e.g. dd if=/dev/random of=/dev/hda).
0
 
LVL 47

Accepted Solution

by:
David earned 800 total points
ID: 33641366
Shred or wipe won't do it.  It is not a matter of just getting drivers.  The RAID controller presents a logical device to the booted O/S, not the physical drive.  You can wipe it all day long and it will still leave data there.  The "drivers", even if you had them, facilitate communicating at the logical device level.

You need to get yourself a JBOD SCSI controller and hook them up that way

0
Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

 
LVL 4

Assisted Solution

by:PcGod718
PcGod718 earned 800 total points
ID: 33641661
im gonna have to disagree on that one dlethe. unless im misunderstanding you, wiping the drive, whether it was in a raid or solo, will wipe the drive.  if i pull a drive out of a raid 5, and put it solo on a system and reformat it, when i stick it back into the raid, it will need a rebuild, because the drive is wiped.

what he needs is some form of access to the drives, in this case since it was a raid, he needs physical access (either 1 drive at a time or all together, doesn't matter) but the drives must show up in whatever OS/utility he uses.

on re-reading your statement a few times, i retract my disagreement,  i now understand what u are saying and i agree  :)  

You can use the raid controller on the compaq to blow out the drives as well, but we all know that isnt secure, although ur average techhead wont be able to get anything off of them.

Anyhoo, i stand by my first suggestion.  wipe the drives 1 by 1 with a standard scsi controller, or just break em.  :)

0
 
LVL 12

Assisted Solution

by:mccracky
mccracky earned 400 total points
ID: 33641820
@dlethe: shred or wipe would do the same as DBAN, wipe the data on the drives.  It may be that the RAID controller presents a logical drive, but the data was put on them that way, so wiping them the same way should do the data the same.  Or reconfigure the RAID to JBOD and wipe them that way or pull them and hook them to a different controller like PcGod718 said.  wipe the actual drive rather than the partition like I said (/dev/sda not /dev/sda1).  Or just go out and mix up some of that stuff that burns through metal and melt the drives.  Or just use them for target practice at your local rifle range or....

There are many ways...
0
 
LVL 47

Expert Comment

by:David
ID: 33641840
Ordinarily yes, but you are forgetting the drive metadata.   That will always remain.  Prove it to yourself.  How many blocks are usable on the disk as reported by ACU?  How many blocks are on the disk as reported by the label?

Or wipe a disk this way, put it in a PC with a JBOD SCSI controller, and just read first few blocks.  
0
 
LVL 56

Expert Comment

by:andyalder
ID: 33645081
It doesn't matter that you haven't wiped the metadata since all the user data will have been wiped which is what matters. You won't have wiped the S.M.A.R.T data either but who cares.

Newer Smart Array controllers provide Int13H BIOS extensions so DBAN etc would see them without a driver but not so for the older ones so putting them on a non-RAID controller is normally the way and it's probable that the server has one inbuilt into the motherboard - can't be absolutely certain as don't know generation number. In that case all you need to do is move the cable from RAID controller connector to motherboard connector.
0
 
LVL 47

Expert Comment

by:David
ID: 33645600
The  DoD, and NIST specifications for erasing a disk require 100% of the disk to go through the procedure.  This is not negotiable.  One of the reasons is that if somebody wanted to, they could put all sorts of information in the "metadata" area like credit cards, and it would survive the process and nobody would know except for the person that put it there, and the person that acquired the disk later.

Also the 5220M and NIST Clear validation passes dictate 100% read validation pass.  Metadata will fail it.

So technically you can only erase some of the disk with DBAN this way.  If you require any level of compliance, then you simply can not do it with your controller in the mix.
0
 
LVL 56

Expert Comment

by:andyalder
ID: 33646108
The metadata can be erased with System Erase anyway.
0
 
LVL 47

Expert Comment

by:David
ID: 33646187
yes, but the validation suite specifies that you have to run the n-erase passes in order, for the entire disk, then immediately follow with a full verification on all addressable blocks.  Yes, it will ultimately be erased this way, but it will not be compliant to any formal specification.  This may or may not be acceptable for the author.  I am just bring up the point that they can not erase the disk per any of the formal data sanitization specifications unless they use a different controller in that system.
0
 
LVL 56

Expert Comment

by:andyalder
ID: 33646712
Hmm, would you know if DBAN tries to erase sectors that have been spared out by the disk because of unrecoverable read errors and the area at the end of the disk that isn't seen if one has set the size of the disk to be smaller than the physical size? Compaq/HP (and Dell) fix the reported size of the disk to be a bit less than the maximum to allow them to use more than one source of disks but maintain identical sizes.
0
 
LVL 47

Expert Comment

by:David
ID: 33647203
I know for a fact that DBAN does not do this, as I have the source code (well, the source code as it was Dec 2009).  I was working on a large sanitization project on a site that had a bunch of  HP G3 and higher servers, and was hoping I could use DBAN .. had to do something else, because of the SMARTArray controllers.   Luckily they had plenty of the JBOD enclosures and tape libraries, so just moved the JBODs to the controllers reserved for tapes.

DBAN (at that time, and unless there has been a change) will not address disks that have had capacity changed via CHANGE CAPACITY CDB.  Nor does it facilitate doing anything about the grown defects. This is true for both ATA family and disks that use SCSI protocols.    Also it was quite annoying that DBAN requires you to boot the system, and it is also profoundly slow. I was able to get a single server to wipe 288 HP FATA & Fibre channel disks concurrently using another product that has much more intelligence.  It took maybe 24 hours to get the approx 150 FC drives to go through the 3 write passes, maybe another 48 hours to get the FATA drives done).  I had to add multiple controllers to the system so that I would not saturate all of the pipes, and certainly could have done it faster had the HP server had PCIe 2.0 bus, but still this part was rather painless.   The annoying thing was that we were constantly moving around those 5-1/4" SCSI drives in and out of the same 6 expansion units to keep everything going. Still we did over 1000 disk drives in a secure cage  where you couldn't bring in any hardware other than cables & controllers due to the nature of the data in just a few days.

DBAN is a good product, but it is more of a consumer product.  it isn't designed for volume and won't do in-band erasing on native windows, solaris, unix, etc..
0
 
LVL 56

Expert Comment

by:andyalder
ID: 33650424
So in other words not erasing the metadata and what may be hidden by it is pretty irrelevant since most permanent erase programs also leave holes where data could be sneaked out surrepitiously?

If DBAN could erase the user data while it was still on the RAID controller (not in this case as no drivers) then any accidental data loss would be covered and only deliberately obfuscated data would get through?

I'm just trying to qualify what you mean by "the whole disk" since there's manufacturer's data (firmware etc.) on what one could consider negative tracks on the platters.

If not erasing through a RAID controller isn't sufficient is anything sufficient except a grinder?
0
 

Author Closing Comment

by:NoneProfit
ID: 33809209
Thanks for the help. We are taking the easy way out and drilling holes!
0

Featured Post

Connect further...control easier

With the ATEN CE624, you can now enjoy a high-quality visual experience powered by HDBaseT technology and the convenience of a single Cat6 cable to transmit uncompressed video with zero latency and multi-streaming for dual-view applications where remote access is required.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Compliance and data security require steps be taken to prevent unauthorized users from copying data.  Here's one method to prevent data theft via USB drives (and writable optical media).
New style of hardware planning for Microsoft Exchange server.
This video teaches viewers how to encrypt an external drive that requires a password to read and edit the drive. All tasks are done in Disk Utility. Plug in the external drive you wish to encrypt: Make sure all previous data on the drive has been …
Finding and deleting duplicate (picture) files can be a time consuming task. My wife and I, our three kids and their families all share one dilemma: Managing our pictures. Between desktops, laptops, phones, tablets, and cameras; over the last decade…

721 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question