Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is my setup:

  • Lenovo ThinkServer RD140
  • IBM ServeRAID 8k controller
  • Four Seagate Barracuda 1TB hard discs, organised in two RAID-1 arrays

Now the third disk is defunct (orange light flashing). I removed the third drive (hot-swappable) and replaced it with a spare 2 TB Seagate Barracuda (did a Google search and found that it's ok to use a larger drive). Nothing happened (i.e. no reconstruction).

I booted the server and opened to the RAID controller UI. It lists the first RAID as "Okay", the second RAID as "Critical" with a missing disk. It finds the new disk, but doesn't allow to associate the disk to an array.

I decided to format the new disk. After several hours, I got inpatient and rebooted the server. The first RAID came up, causing the (ESXi) server to boot regularly, the second RAID still is "Critical", the data is not accessable.

Now my plan is to discard the new 2 TB disk and get a new 1 TB disk as soon as possible. (Time matters.) Hopefully the RAID will rebuild with the right disk and be accessible again.

  • What can I do to access the data on the second RAID?
  • Have you got a recommendation how to proceed?

Thanks a lot for your help!

share|improve this question
I'd call up IBM and say ~"what the hell??" Not that "tech support" has a reputation for knowing what they're doing, but if anyone should be able to tell you why your IBM server and RAID controller won't accept your new disk, it would be IBM. – HopelessN00b Aug 1 '12 at 11:53
up vote 0 down vote accepted

The new 1 TB disk lead to a successful RAID rebuild. So maybe I got a new but damaged disk or maybe the size was too wrong (although the manual states the size does not matter als long as it is bigger or equal to the previous HD size).

Data was in fact accessible, but rebooting the virtual machines was not successful because of a kernel update that did not succeed. The machines had not been rebooted before. The message stating that the filesystem could not be accessed made me assume it had to do with a RAID problem which was not the case.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.