0

I am attempting to recover a HW RAID 5 setup from what appears to be a failing motherboard chipset.

The BIOS can detect the 3 individual drives, and the RAID ROM detects all 3 drives as member drives.

The unusual behaviour then begins when attempting to boot with the RAID connected, any attempt to boot to any drive (RAID, seperate HDD, CD, USB) results in a black screen with a white horizontal cursor blinking in the top left corner. The system will then hang there, or reboot and try again. There seems to be no relation between which times it hangs and which it reboots. Disconnecting the RAID will still result in the same behaviour for some time afterwards, after an indeterminate number of reboots following disconnecting the drives the system will boot fine. The same behaviour occurs for all operating systems.

I have tried a number of suggestions to how to get the system stable including the following:

  • New OS HDD
  • All new SATA cables
  • Clearing CMOS
  • Resetting BIOS to defaults
  • Updating BIOS to most recent stable version

Any further suggestions as to how to get the system stable enough to copy the data off to a non-RAID drive?

System Specifications:

  • Gigabyte GA-Z77-D3H
  • Intel Xeon E3-1240V2
  • 4x Corsair 4GB 1333MHz Cas15 Non-ECC
  • Nvidia Quaddro FX380
  • 3x WD Red 3TB (RAID drives)
  • 1x WD Red 3TB (Fresh drive for backup onto)

EDIT: The issue has been identified, at some point the BIOS sata controller has changed from RAID to a single drive option (AHCI or IDE) and corrupted the first drive in the array with a microsoft reserved partition. Each time the machine boots into windows the iRST is attempting to rebuild the array, whilst microsoft is attempting to use the corrupted drive, the conflicting actions causing the system to lock up and crash. Removing the corrupt drive and replacing with a fresh drive has brought the raid into a stable rebuild mod. The system will now boot happily into a linux OS running on a USB flash drive (Debian seems to be the most stable) from which the RAID can be accessed and the data backed up. Booting into any windows installation still crashes so that will be a later problem to be solved after the data is all safe.

Improve this question
3
  • 1
    Obligatory: RAID is not backup. RAID just minimizes downtime. If you're taking all this downtime to recover data, your choice of this RAID 5 arrangement was a huge mistake.
    – David Schwartz
    Commented Dec 29, 2016 at 12:03
  • I understand this, and that is why the majority of the data on the array is already backed up externally. RAID 5 was chosen to provide single disk redundancy without the cost of duplicating every disk internally.
    – Karznah
    Commented Dec 29, 2016 at 12:11
  • Get vendor support or try it on a system with the same mainboard/raid chipset. Did you disable the RAID BIOS in your BIOS? Can't you boot with the RAID connected at all? As the issue persists I'd not expect it to be connected to the RAID.
    – Seth
    Commented Dec 29, 2016 at 13:17

1 Answer 1

Reset to default
0

So after many weeks and many potential solutions I have managed to recover the data by assembling the RAID set within Debian and copying over to a fresh drive. This kept failing and requiring the system to be restarted and the array reassembled with mdadm.

After recovering the data, the system was rebuilt with a fresh hard drive in a non-RAID configuration. The instability remained, crashing randomly and during any intensive read/write periods. From this I have deduced that a failure has occurred with the sata controller in the chipset. Sadly the only solution I could find was to replace the motherboard, and have taken the opportunity to upgrade the system and start a new build.

TLDR: Problem still unsolved, entire system replaced, so no more updates or solution.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .