1 of 1 people found this helpful
If the data on the disk itself was untouched, you should be able to rebuild the array. The RAID metadata is on the disk itself. i.e. You can take an array from a ICH9R controller and rebuild it on a ICH10R fine.
Pure speculation but it maybe the disk is no longer the "registered" member of the array?
In this case nothing has been written to the drive so the repair is quite simple. One must destroy and re-create the array in the Matrix BIOS, then use a disk repair tool to find and revive the partition(s). Additionally, the drives' master boot records may need to be re-written. The whole process takes about five minutes.
Part 1: Recreating the array in the BIOS ("Intel Matrix Storage Manager Option ROM")
1. Note all of your array's attributes(1) as shown during boot: array name, RAID level, member disks, strip size, and capacity. From the Matrix menu choose option 3 - Reset Disks to Non-RAID. Select all disks which are shown as being part of the failed array and follow the prompts(2). You will then be returned to the main menu and those disks will be shown as Non-RAID Disk or similar.
2. Now choose option 1 - Create RAID Volume, and enter the exact same settings as before (name, RAID level, member disks, strip size, and capacity). The array volume name probably doesn't need to be the same, but I wouldn't risk changing it.
Part 2: Recovering the partition tables in TestDisk (or other partition recovery software)
3. After rebooting, use a backup OS of your choice (on a removable drive, or installed temporarily on a different hard drive) to run Christophe Grenier's TestDisk - a free, open-source recovery program. Others will probably work as well, but this one is fast and does the job very well.
4. In TestDisk, select your disk (which in this case is actually the array)(3) , then your partition type (in my case, it was correctly auto-detected as "Intel/PC"), and choose Analyse. Since the Matrix BIOS has invalidated the partition table information, you will not see anything listed. Now select Quick Search and follow the prompts. If all is well, you will quickly see your existing partitions appear. Once it lists them all, you can hit Stop to avoid waiting as it scans through the rest of the disk. If the detected configuration is correct(4) , press Enter to continue to the next screen, and choose Write to update the partition table as shown.
Part 3: Correcting the Master Boot Record
5. The Matrix BIOS has also invalidated your array's MBR, so it will need to be retrieved or replaced. There are many ways to achieve this, and TestDisk itself has several methods to do so(5). I prefer to boot to my Windows 7 installation disc and use the "Repair your computer" option(6) . It will detect the invalid MBR and prompt you to fix it - note that you can't alter Windows' proposed changes, only apply or dismiss them. The resulting boot manager behaviour(7) can be viewed from the "Click here for diagnostic and repair details" link, if changes are necessary you can open a command prompt and use Windows' bcdedit command to do so, or if you prefer a GUI (and can get into Windows) you can use NeoSmart's EasyBCD, which is freeware.
Notes and troubleshooting:
(1) If all disks in the array are shown as "Offline Member", the array information will not be visible. Booting with only one previously RAIDed disk plugged into the motherboard should cause these details to be reappear so you can write them down. (It will also change that disk's status to show as "Failed"). Repeat with one disk from each array if you have several.
(2) There will be a warning that says all data will be lost. Ignore this, it is untrue (unless you don't follow the rest of the steps, of course.)
(3) Depending which OS you run TestDisk from, the drive's manufacturer may not be listed. Alternatively you may just not be aware of who makes the controller for your specific drive. In these cases it will be necessary to identify the correct entry by its listed capacity, which will be very close to that entered when creating the array in the second step.
(4) The partition layout detected in the first few seconds will usually be correct; I would not recommend changing anything unless you're certain it is wrong. Keep in mind that installing Windows 7 often creates a hidden ~100MB partition on the system drive.
(5) See details at TestDisk Bootsector Recovery - CGSecurity.org.
(6) See details at Win7 Startup Repair Tool - About.com.
(7) Did you have multiple OS installations, some of which were already broken (or that required a different combination of hardware)? Murphy's Law dictates that one of these will be set to boot as default. Verify the OS you want is actually the one being loaded before worrying that this fix did not work.
(8) All the TestDisk operations described are shown visually at TestDisk Repair Tutorial - CGSecurity.org.
(9) The above procedure was gleaned from this thread, and is originally credited to Yasin Abbas, aka YaZ.
@DuckieHo: Indeed. I did come across suggestions that it may be possible to repair the array from the Matrix/RST console, but since the broken array held the OS the above solution was much faster than installing Windows on another drive to find out. Since the iMSM BIOS does not include any options to alter an existing array, it would be good to know whether RST can do this - but unfortunately the available documentation does not go beyond using the software when there are not any problems. I ran into the same issue replacing a working but "degraded" drive earlier in this same system - simply setting the replacement as a spare drive in RST caused the bad drive to be copied and ejected from the array. While this might seem like expected functionality to someone experienced with using RAID arrays, it doesn't seem like a good idea to skip documentation of procedures which are not normally available!
Hi TGentry! Thanks for the above posts.
It saved my *** from a reinstall after running Diagnostics on a Samsung HDD within ESTOOL.exe. ESTOOL.exe within diagnostic test writes out some bytes to the very beginning of the disk destroying RAID and MBR infos (it was a RAID0 setup). Recreating ARRAY and scanning with TestDisk recovered partitions. Windows 7 recovery repaired MBT and all in 5 minutes it was up and running. It took me more time to find this thread than repairing.
Really appreciate this knowledge.
After several unsuccesful attempts I came to realize that the only way to get any further in my case was to reset the remaining disk in the array to non-raid. And despite the warnings no data was affected only the array. The lesson for Intel must be to elaborate a bit on the warning in the window with plenty of room to do this. The warning states that the data will be deleted but this is not true - it is only the array that is deleted.
I'm currently backing up my array using R-Studio's virtual raid but I'm almost certain that the backup won't be needed - I will create a new array using the same parameters and if I'm correct everything will return to normal using existing disks and data.
Well, it's been a while since I started this thread, and I'm glad to see a few people have had success with the fix. I had planned for a while to clean up the procedure a little - little did I know I'd need it again myself for another problem.
I needed to use a sanitary erase program for an older SSD, but the computer it was in did not support SATA. The application I planned to use (HDDErase) only works on integrated controllers, so it would not detect the drive plugged into the PCI-based card. I decided the fastest way to get it done would be to plug it into my ICH10R-based board and wipe it from there. To prevent any disasters I unplugged all the other drives, then switched the SATA mode from RAID to OFF (aka "legacy mode").
The program did not detect the drive, so it was a failed attempt. But what's worse, after re-attaching my drives and re-enabling RAID mode, the array status was shown as FAILED and while both disks were detected they were shown as "Offline Member". I tried several methods to rectify this, including fooling with the BIOS and changing cable order. The last attempt was a guide on the Ubuntu forums claiming that starting the machine from a LiveCD and installing dmraid (or running gparted) would revive the array. No success there, either.
I finally returned to the method detailed in this thread, and I'm glad to say that it worked for this issue as well. Until next time!
I ran in a similar problem yesterday with our ICH9R
I followed you instruction but I can only see the folders structure (no
files). I'm now on my second attempt but this time using the "Deeper Search"
option hoping my file can then be seen...
Please let me know if you're having other suggestion
Thanks for your post that was helpful
Just wanted to stop in and say thanks. I was able to follow your instructions and rebuild my Raid 0.
For some reason my bios returned to default. I think I may have a bad cmos battery, so it lost the raid config. I used this to solve it. One of my partitions was a bit wonky I guess, had to fiddle with testdisk for a while, but eventually got it working. Anyways thanks!
Thank you for this excellent guide. There is one issue with this I would really like to get a definitive answer to.
The issue is described in another excellent thread running on this topic here
and it is that some users lost their RAID data after they re-built the RAID and re-booted into Windows to run TestDisk (on your guide this is at Step 3).
This was because the Intel Matrix Storage Manager initialised the re-built RAID.
Now I am not an expert on the inner workings of the Intel Matrix Storage Manager so I cannot be definitive about the cause but there is enough anecdotal evidence in this thread to warrant consideration if your RAID data is important to you.
It appears that to minimize the possibility of this catastrophic event, the Operating System used to run TestDisk to recover the RAID partitions should not have the Intel Matrix Storage Manager installed. The Intel Matrix Storage Manager should be uninstalled at the start and before the RAID is re-built. This applies in particular to computers where the Operating System is already resident on a non-RAID drive on the computer but should also be applied to an external temporary Operating System installation. It also seems that the Intel Matrix Storage Manager can be re-installed without issue at the end of the process (after Step 5 in your guide).
As this is an Intel forum, it would be great if there was some Intel(ligent) expert lurking out there who could log in here and explain fully how the initialisation process gets started and confirm if the above method is how it can be avoided.
I would like to add two further points of information if I may:
Point # 1
After and only after the completion of the recovery of the partitions (Step 4 on your guide), and before progressing further, there is an opportunity to use TestDisk to copy critical data to a non-RAID or external drive. This may be a good insurance policy against a failure of the next steps of the recovery procedure if you have critical files on the RAID that have not been previously backed up.
After using TestDisk to Write the partitions per Step 4 of the guide, on the Test Disk screen, use the up/down arrow keys to highlight the relevant partition and type p as directed at the bottom of the screen to list files and folders. Current files and folders are shown in white. Previously deleted files and folders are shown in red. You do not need to copy the red files/folders.
Use the on-screen instructions and the up/down/left/right arrow keys to navigate to the critical data folder and press c to copy.
At the copy Y/N prompt, by default Testdisk will copy the folder to wherever the TestDisk program is run from such as the testdisk-188.8.131.52.win\testdisk6.11.3\win folder if you are running TestDisk version 6.11. To copy to this folder hit Y.
If you want to copy the critical data folder to the root of the TestDisk drive, keep pressing the left arrow key to change the directory to the root drive letter of the drive and hit Y to copy.
Copying large folders will take some time.
Repeat the copying procedure for other critical folders.
Like me, your RAID system may be on a computer that does not support the addition of another internal drive on which to install a temporary Operating System and does not come with an Operating System install CD to execute the repair of the master Boot Record (I have two Sony Vaio Vista laptops that came pre-configured with RAID 0 like this). One solution is to download and burn a bootable NeoSmart Recovery CD of your Operating System from here (cost is less than $10):
To run the TestDisk program from a USB drive using the NeoSmart Recovery CD (if your are trying to recover your RAID system using TGentry’s guide, this is Step 3 of the guide, you will have already completed Steps 1 & 2) do the following:
At the end of Step 2 of the guide, set the BIOS boot order set to boot first from the CD optical drive if it is not already set as first by default.
Connect a USB stick/thumb/drive that contains the TestDisk program. If the Operating System of the NeoSmart Recovery CD is XP, the USB drive will need to be connected before booting.
With the BIOS boot order set to boot first from the CD optical drive and the NeoSmart Recovery CD inserted, the computer should now boot with the Neosmart Recovery CD. Be ready to quickly press any key at the “Press any key to boot from CD/DVD” prompt. This may be critical in avoiding booting into an operating system where the Intel Matrix Storage Manager is installed leading to RAID initialisation and data loss as described above.
After booting, once the language page comes up, select Next and Repair your Computer.
No operating system may show or may show with errors. In any event click Next and Command Prompt.
Do not attempt to use the Startup Repair or Restore tools at this time.
At the Command Prompt, type cd\ and press Enter.
To find out what drive letter the USB drive is we can use the Notepad application.
Type Notepad in the Command Prompt, press Enter, click File and Open, then click Computer on the left pane, this will show you the drives. Note the drive letters may be different than those assigned in the normal Operating System.
You can launch TestDisk from here as well.
Change the Files of type to All Files.
Navigate to the USB drive and then the folder with the TestDisk executable file (in my case as I use TestDisk version 6.11) the \testdisk-6.11.3.win\testdisk-6.11.3\win folder
Right click on testdisk_win.
Click Open and use the TestDisk program per Step 4 of the guide.
The NeoSmart Recovery CD Repair your Computer Startup Repair function or Command Prompt function can be used to repair the Master Boot Record per Step 5 of the guide. Remove all USB connected drives before attempting the repair.
I am having trouble I need some help with.
I have an Asrock Extreme4 Z87 mobo with a 4770k i7. It was working good and I installed windows 7 x64 onto an SSD drive in ACHI mode. I later decided I wanted to build a 9TB scratch disk RAID 0 array of 3 drives x 3TB 7200rpm Toshiba drives. I booted into BIOS and changed from ACHI to RAID mode and build the array. But when windows booted it BSOD on me, I assumed it was an ACHI thing. So I changed back from RAID mode to ACHI mode in the BIOS and amazingly my RAID 0 drive showed up at 9TB drive. I formatted and used it.
Recently my system has developed some slow lagging and hang up on the first BIOS screen. I thought it might be the mobo so I flashed the BIOS to the newest version for my motherboard. That went fine. But my RAID 0 array was lost.
I have a bunch of posts with screen shots in one of my threads on AVS forum for my server (but this is my desktop)
I have clean installed windows 7 x64 in RAID mode thinking that would fix my problem. It did not.
I blew out the old array and rebuilt it exactly the same but still windows did not see it. I have not formatted or changed anything on my hard drives.
I need some help rebuilding this array and recovering my data! please help!
You may want to follow the steps from post number 6 (adamsap) here: http://forums.extremeoverclocking.com/showthread.php?p=3329132
I believe it is similar to the above post by TGentry but I cannot guarantee the result since it is something we just found over the internet.
Thanks I will check it out. My trouble I think is I booted into window and even clean installed to another OS drive. I've done this in both RAID mode and ICHI mode and my drives seems to have switch back and forth from GPT to MBR because in my disk manager in windows they showed as 746 gigs each ( isn't that 2TB limit + leftover for a 3TB drives I am using ?)
I have not changed or formatted anything on my drives and they are installed on the same ports still.
Think I am screwed or would it still work ? In the link I posted to server thread in AVS there was a couple other ideas floating around too. I really hope I can recover this data. Thanks again for the help!
It is 2015 and Intel chipset RAID controller (Intel® Rapid Storage Technology in my case with option ROM version 184.108.40.2066) still tends to lose RAID members after firmware upgrade. I have system built on MSI Z97 gaming 3 motherboard and I created RAID 0 volume on Z97 chipset ports from 4 SSD disks (it is used as system/boot disk). After MSI released new firmware for motherboard I installed it from UEFI BIOS. System restarted after firmware installation and SATA ports were reset to AHCI mode. After restoring SATA ports to RAID mode, RAID 0 array recognized only three SSDs as members and one SSD as separate disk not belonging to any RAID volume. Lucky me - I found this thread with detailed instructions so I recreated RAID 0 volume but disk was not bootable. Then I booted system from windows 8.1 installation CD and in command prompt run 64 bit version of TestDisk from USB key but results from several TestDisk runs were inconsistent so I tried to find another solution. My system used GPT partitioned disks so by design there should by partition table backup at disk end. So I put 64bit GPT fdisk program to USB key and run it in system booted from windows installation CD. It found that both (main and backup) GPT partition tables where in perfect condition (there are checksums on disk for checking state) and only problem was missing very first sector (in GPT terms called protective MBR) that could be fully regenerated by the same GPT fdisk tool without any loses. So with GPT fdisk I regenerated this protective MBR (just by saving loaded from disk GPT partition table) and after reboot I got back to my intact Windows 8.1 system (there was no need to run any repair utilities). So this means that RAID creation process zeroes only first volume sector (512 bytes) which in MBR partitioning scheme (older or 32 bit systems) are very valuable thing and should be restored/repaired using TGentry provided steps 2 and 3 and with GPT partitioning scheme (new UEFI 64 bit systems) this overwritten sector is critical for system to recognize disk as GPT and boot but could be regenerated with simple GPT partitioning tools without any risks.