Nuke and rebuild is what im hoping for that might work. Ill be waiting on you too see if it works before i move on ahead with attempting to repair the array as it stands.
Played stalker 2 yet?
Thinking about all of this adaptec business makes me wanna buy up a broadcom tri mode card. Just sontheres no failures incase of a a hot remove.
Designing a system that can handle power failures at any time is difficult, but usually itâs ZFS that has trouble with unclean shutdowns destroying arrays, not hardware raid. I still think the expanders are what triggered your initial problem.
Iâm trying to hurry up my playthrough of Anomaly H.A.C.R. before I start on 2.
1 Like
Man its a damn masterpiece. Kinda makes me wanna go back and actually play atmoic heart.
https://www.newegg.com/global/au-en/broadcom-05-50107-00-sata-sas/p/N82E16816125028?source=f
Something like this i think would be good enough. I have a question about onboard ram for these. When would i ever need more than 4gb @3200mhx? On a hardware raid.
I remember the hype when that game was coming out but then I didnât really hear anything after and it flew under my radar.
for me the appeal of the broadcom cards is that so many of them were sold that you can actually find them for reasonable prices on the second hand market; probably best to stay away from the chinese special cards though.
more ram is always better, but 4GB is probably fine. another thing to look out for with the ram is dual channel vs single channel ram; it seems like the x16 PCIe cards get dual channel ram while all the x8 PCIe cards get single channel ram.
1 Like
Yeah, i dont think this would of happened at all if im honest with you. With another card like a Broadcom. It just feels like this is baked in pay-to-win typendeal into adaptec card.
Its just way too suspect. Something like this. I would imagine the data points or some kind of short-circuit would only destroy parity data.
Its too illogical. And sad aswell because these arrays can become quitenfool-proof. And the only lie-ing point of failure being loss of power/hotnremove. Its too adolescent for this too be a thing
The drives arrived late last night. Have a RAID-5 array building right now. I will copy the RIS data off and save it.
After I have a copy of the RIS data saved, I will nuke the array and attempt to rebuild it using ARCCONF version 2 with SKIP. I have a single Hello_World.txt file on it. The background parity init is only 58% complete - this is with six 2TB drives. Hoping to have some answers tonight or tomorrow at the latest. RAID-10 next.
2 Likes
Nice, have you already deleted the array off the controller? Or does it just boot the array into a broken parity of disks like mine atm?
I am curious to see if you delete the array, and then when you go to create a new one if ot auto-picks up, the old array you had. Which is all i can really do to get my array back. Good to hear the news. Lets see how it goes.
Hi, my controller lost all of itâs arrays. I removed one drive from my last (âEâ) array which was only RAID-0. When I did that and rebooted - all of my arrays were missing and I needed to remove them from the /etc/fstab in order to boot my system.
All of the arrays I have are data - none of them are O/S data or are bootable. In one fell swoop, I lost 76TB of data - with no recovery actions suggested by Adaptec/Microsemi.
I received an email this morning - Microsemi tech support is closing my ticket and marking it âsolvedâ. Nice to know they really care about customer service. 
1 Like
I am moving rather slowly on this - trying to document my every move, so someone else might benefit from the disaster that poorly coded firmware caused.
My primary use of the arrays were for Video storage - I bought an external drive to use for that, so I could take my time. My Windows storage has a lot of information I would love to recover - that is my second priority.
Right now I am changing the RAID adapter settings to use HBA access instead of RAID - but I might need to damage my array to do that. Unable to change it in the BIOS RAID setup, tried doing it in maxView Storage Manager, it complained. But I can do it at the connector level (there are four of them in my controller) or at the controller level. I will see if I need to override the connector setting so I can harvest the RIS data that lives in the last 32,768KB of each drive.
1 Like
Hate to tell you, but thatâs exactly why RAID0 should never be used.
Itâs of little consolation to you, but hopefully itâll prevent others getting into the same predicament 
1 Like
Have a read of my thread. Its just not something I would suggest produxt support do really.
I mean. This is such, SUCH, an adolescent problem, for the controller not to be able to recognize or auto repair, is beyound me. We can see the issue plain as day, yet the arcon commands dont exist to force it online. Irs just ridiculous, and in my thread and cant force on the âdisconnectedâ drives. To be able to set a âbuildâ list of array parameters and then reboot and have the controller negotiate its initialisation or something. Like it seems do-able.
Anyway i hope u get ur data back theres a few other things i might try before deleting any arrays.
At no point in time were any of my data arrays RAID-0. I was migrating data to a replaced drive (14TB - that was swapped for new 16TB drives) That drive is fine, the data on it and my other RAID-0 drive was not lost.
Please pay closer attention - before commenting. As an old IT fossil, I have been around a lot longer than RAID has. Hardware-level disk recovery is something I have done, along with a whole host of other rather advanced system-level work.
I removed the last drive in my system on the last RAID-0 array I created to migrate data to. There were four other arrays. After removing that single drive - everything else disappeared.
Hardware RAID is never supposed to work this way. Something in Adaptec/Microsemi firmware screwed the pooch - and removed the RIS data from all but one of my drives. (the dedicated hot spare for the RAID-5 array) After reading a few different support articles, I came to the conclusion that my hot spare stale RIS data might be the problem. Unfortunately, it likely held the âcorrectâ RIS data for my arrays.
After clearing the âstaleâ RIS data from that drive - I was toast.
My goal now is to find a path to recovery, so I can share that secret with the rest of the audience here. I have many pressing things to do besides work on my NAS in the next few days - so progress will be slow until Saturday.
I hope to glean the RIS data today - and rebuild my test RAID-5 array using ARCCONF version 2. If that works - there is hope for recovery of my original RAID-5 array. In addition, there is a small amount of hope that I can also recover my RAID-1/0 array.
When I finish testing with the RAID-5 array, I will blow away my test RAID-5 and create a four-drive RAID-1/0 array and repeat most of the same steps. I am hoping to see data from both of my arrays before Sunday.
I saw that there is the command arcconf setstate from Can a failed array be recovered?
arcconf setstate help
Controllers found: 1
Usage: SETSTATE <Controller#> DEVICE <Channel# ID#> <State> [noprompt] [nologs]
Usage: SETSTATE <Controller#> DEVICE <Channel# ID#> <State> [ARRAY <AR#> [AR#] ... ] [SPARETYPE <Type>] [noprompt] [nologs]
Usage: SETSTATE <Controller#> LOGICALDRIVE <ld#> OPTIMAL [noprompt] [nologs]
Usage: SETSTATE <Controller#> MAXCACHE <maxCache ld#> OPTIMAL [noprompt] [nologs]
Example: SETSTATE 1 DEVICE 0 0 HSP ARRAY 0 SPARETYPE 2
Example: SETSTATE 1 LOGICALDRIVE 0 OPTIMAL
Example: SETSTATE 1 MAXCACHE 0 OPTIMAL
Example: SETSTATE 1 DEVICE 0 0 DDD
===================================================================================
Redefine the state of a physical or logical device from its current state to the designated state.
DEVICE parameters
Channel# ID# : The Channel and ID of the device whose state will be altered.
Physical states : HSP : Create a hot spare from a ready drive.
Optional [ARRAY <AR#> [AR#] ...] parameters
Dedicates the HSP to one or more arrays.
: RDY : Remove a hot spare designation.
Optional [ARRAY <AR#> [AR#] ...] parameters
removes a dedicated HSP from one or more arrays.
Attempts to change drive from Failed to Ready.
Some controllers do not support this option.
: DDD : Force a drive to Failed.
: EED : Enable an erased drive.
Logical states : OPTIMAL: Force a logical device to Optimal state.
ARRAY <AR#> : The array to which the device will belong to.
LOGICALDRIVE or MAXCACHE parameters
ld# : Logical device ID to be forced optimal.
maxCache ld# : maxCache logical device ID to be forced optimal.
SPARETYPE : Sets the sparetype for the array.
Type : 1 : Dedicated - A dedicated spare temporarily takes over for a failed
drive and can be shared between arrays.
: 2 : Autoreplace - An autoreplace spare replaces a failed drive and cannot
be shared between arrays.
noprompt : An optional parameter that suppresses the user confirmation prompt.
nologs : An optional parameter that suppresses log output to the log files.
Command completed successfully.
That link was very informative, im going to try and force online in advanced mode through the bios innthe next few days.
I also want to vhange my array configuration and onlynuse 2 expanders. Ill do it all and report intonthis thread and mine if you like.
Can i ask why your using a raid 1 /0 array instead of a raid 6?
I only aks why a raid 1/0 because you only get to use a quarter of the storage space you create,
When hardware raid 6 gives you most of your storage with good speeds and is redundant.
Hi, using RAID-1/0 which is 1/2 the total space for speed.
4x10TB RAID-1/0 = 20TB but it is really fast. I wanted fast access using SAS drives and it is my only array that uses the 4GB cache on the controller.
Good news - I disconnect the drives from the Adaptec/Microsemi adapter and plugged directly into my six spare SATA ports on my mobo.
Found the RIS data on the drives. It lives about 12MB into the last 32MB of each of the drives. I still see a few of the drives from my broken array in the metadata. Need to study it a bit closer to figure out if a drive is live or deleted.
Here is a dump in hex and text of what I see for an active drive for my RAID-5 array.
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F Decoded text
000 59 46 47 5A 5A 5A 5A 5A 20 20 20 20 20 20 20 20 YFGZZZZZ
010 20 20 20 20 4D 4B 37 4F 41 38 34 30 41 54 41 20 MK7OA840ATA
020 20 20 20 20 48 69 74 61 63 68 69 20 48 55 41 37 Hitachi HUA7
030 32 33 30 32 00 00 00 00 00 00 00 00 00 00 00 00 2302
040 00 00 00 00 00 00 04 91 00 00 00 01 EA A7 54 B4 â ĂȘ§TÂŽ
050 00 00 00 00 01 59 61 33 00 00 00 03 00 00 00 00 Ya3
060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
070 00 00 00 00 FF FF FF FF 00 00 00 01 00 00 00 00 ÿÿÿÿ
080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
090 00 00 00 00 FF FF 00 00 00 00 00 00 00 00 00 00 ÿÿ
0A0 00 00 FF FF 00 00 00 00 00 0A 00 00 00 00 00 0A ÿÿ
0B0 01 35 02 04 06 03 29 01 00 00 00 00 00 00 00 04 5 )
0C0 00 00 00 00 01 85 02 04 0B 00 00 00 00 00 00 00 âŠ
0D0 00 00 00 07 00 00 00 00 01 2A 02 04 06 03 29 01 * )
0E0 00 00 00 00 00 00 00 07 00 00 00 00 01 85 02 04 âŠ
0F0 0B 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00
100 01 28 02 04 06 02 2F 01 00 00 00 00 00 00 01 33 ( / 3
110 00 00 00 00 01 28 02 04 03 00 11 01 DF 3A E6 62 ( Ă:ĂŠb
120 00 00 01 33 00 00 00 00 01 28 02 04 06 02 2F 01 3 ( /
130 00 00 00 00 00 00 01 33 00 00 00 00 01 85 02 04 3 âŠ
140 0B 00 00 00 00 00 00 00 00 00 01 46 00 00 00 00 F
150 01 2A 02 04 06 03 29 01 00 00 00 00 00 00 01 BA * ) Âș
160 00 00 00 00 01 2A 02 04 06 03 29 01 00 00 00 00 * )
170 00 00 01 DE 00 00 00 00 00 00 00 00 00 00 00 00 Ă
The Hitachi serial number is Zed out after the first three characters. I will spend some time looking over this to attempt to figure out what active versus inactive entries look like.
My hope is to verify the result of ARCCONF with SKIP on my test array before using it on my broken RAID-5 array. Nice if I can see what changes from before and after the command.
Yeah man for sure, keep us posted
Any progress hombre