• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Areca RAID5 Fail-- need help desperately please

C

Capt.Frito

n00b
Joined
Mar 18, 2013
Messages
30
I need help desperately!. The situation is not a common one so hopefully I will be able to convey the situation clearly enough to figure it out. In the end I need some help trying to restore these RAID sets since it involves both the primary data RAID set and the backup set!

I have two Areca 1882ix SAS adapters connecting to an external drive enclosure by Astek. The enclosure can hold 16 drives in total, but it is divided into two groups of 8 drives each. Each group is on its own dedicated SAS bus and its own dedicated Areca 1882ix, and the these two independent cards are located in the same server managed by a single (non-VM), which is Linux (Gentoo) kernel 3.6.11 using the standard Areca "arcmsr" kernel driver. Things have been fine for a year or so.

Yesterday, I plugged the RAIDs into the Areca cards (I use the external 8088 interfaces) as I normally do. One of the RAIDs registered as "failed". I am 100% convinced that all the drives are fully functional. (Note: These RAIDs are not attached permanently -- I hotplug them when I need them... I cannot leave them attached through boot because they are not system boot drives -- and no matter what I do -- either Grub or the kernel prefers to enumerate hd0 from SAS instead of SATA first so it will find the wrong one when the SAS drives are present.. this is another story for another time).

Here's the thing: The two drives missing from the original RAID set were marked as "failed" but appear in the RAID set heirarchy as their own volume set with the same RAID set name. It seems that for some reason these two drives got split out from the array but that the data on them should be still good. I've read about these things happening with other Areca systems.

Here is a link to a screen capture of the failed RAID set heirarchy. Don't let SansDigital's web gui re-branding fool you, it's for sure an Areca 1882:

http://www.enlightenment.org/ss/e-51473dcb4aa081.86408241.jpg

Here is what the other (good) RAID set attached to the second 1882 looks like -- it was created identically to the first set, and it is how the one above should look:

http://www.enlightenment.org/ss/e-514744de4cf025.30854788.jpg


The question is: How can I just reassociate the drives to see if the data is still good? I can't see how to do this wiithout breaking things completely. It's really important to have the data. I have read in several places to just recreate/rescue the array but just don't "init" it, but I can see how to do this -- the gui just keeps reporting that the RAID set already exists! :confused:

Before anyone starts thinking that I should have backed up the data, well I did... I backed it up to a similar storage box (but made by SansDigital, not Astek). The SansDigital box is divided into two groups of 12 ea 600GB WD RE drives, whereas the Astek one uses two groups of 8 ea 300GB Seagate's.

When I plugged in the SansDigital drive box, it too did the same thing! It marked two drives as bad and "failed" the array. This is why I think the drives themselves have not failed physically -- way too coincidental: two different mfgrs (Seagate vs WD), two different box makers with different SAS expanders (SansDigital vs Astek).

I realize that this may be Areca the card, I am not too sure about that either, I was not paying attention to which 8088 port I plugged the first array nto -- so there's a 50/50 chance it was a different card each time. I'd try it again but I obviously don't want to make anything any worse at this point.

I do have a Wiindows XP 32bit box with a single 1882ix card in it that I could use to fix things if anyone believes that the OS is to blame (the RAIDs are formatted NTFS because I do use the data on Windows systems too... I much prefer ReiserFS, but this is another topic for another day too...)

TIA,
 
So is this a RAID 0? 5? 6? software?

Did you try restarting the computer?

This can be tricky to fix and can really be RAID card dependent. I'd suggest reading the manual or emailing their tech support to ask.
 
Yes I have rebooted this machine several times. It doesn't help.

It seems that this happens regardless of the cable.

I have contacted Areca, but they seem quite confused by the fact that this is not just a static SAS array that gets plugged in once to a card and left alone forever more. I do not believe that Areca anticipated that someone would hotplug different arrays into the same controller. I feel like this is a bug in their driver, actually, but it's hard to say based solely on what is happening to me, although this SAS/SCSI rescan problem has been reported a lot (and so has the problem with Areca cards marking good drives bad, then failing the array, and so on).

I believe that it may have something to do with switching RAID sets when the machine is still running (hot swap). I can do with with (e)SATA, USB, no problem. The kernel is quite happy to re-read the volume information and present the new storage for mounting. But SAS RAID has always been a problem -- SCSI in general, actually -- it requires rebooting despite the claims that it is hot-swappable (ability to change volumes is what constitutes "swappable" in my mind, otherwise it's just one-time hot-pluggable). Although these are hardware-RAIDed multidrive volume sets, the usage model that of USB storage systems. SAS-based RAIDs are usually set up and left plugged into a specific host in a fixed environment.

It is true that you can hot-plug a SAS RAID array using Areca's 1882 (and their 1680) without trouble, provided it is the same array. What cannot be done, it seems, is change the RAID set. Although I have been doing this, it has frustrated me for more than a year that I have to reboot to get the card to re-read the disk volume information correctly. (See my unanswered post from last year here http://forums-web1.gentoo.org/viewtopic-t-928792-start-0.html )

What I believe caused this problem was trying to get the controller to re-read the array using the /sys/bus/scsi/devices/x.x.x.x/rescan hook. I have been doing this for nearly a year. However, quite suddenly, the problem with the Areca card marking drives in raidsets as bad just started popping up. I have four RAID sets in two enclosures. One of the four raid sets is fine, but the other three are having this problem where drives are just being marked as "failed" when they are not. I believe that they just need to be re-inserted into the array in their original position and not reinitialized but I cannot see how to do that. I have rad that it s possible, albeit it tricky.

As an aside: I would not do any of this by choice. These RAIDs are used in a super-high-performance test and measurement system that has to write continuously (and somewhat synchronously) to two parallel storage systems for hours at 600MB/s. And it has to be transportable and reasonably low power (explaining the small volume size of dual 2.1T using 2.5" drives...) When the system was architected a few years ago, this was all that one could do. And the instrument that wirtes to these RAID sets, to make matters worse, is Windows XP based -- so on top of everything else, it's NTFS with that 4K kludge. So in order to deal with these measurement files and work around the NTFS goofiness I have to constantly swap these RAIDs to move measurement files onto a more capable OS and file system. In the time since, the manufacturer has moved onto an embedded Linux and no longer uses SAS hardware RAID and the 4K kludge. But I am still stuck with this messy legacy system. It is no small irony that this problem cropped up as I was migrating the data sets off the old system .:rolleyes:
 
Well, this wont be helpful, but lesson #1, raid is not a backup.

still reading over the thread.
 
Quite a problem I see.

As for getting the data off this one time, you could use r-studio and probably have 100% success.

As for longterm stability of trying to hotplug multiple arrays like USB sticks. It was only a matter of time before corruption would occur.

I do know that some RAID cards will not allow you to replace a failed disk with a known bad disk. Once a disk is marked as failed it's serial number is written to onboard memory. The only ways around this would effectively destroy your array (changing serial number in firmware or resetting RAID card).

However I'm not sure if your specific RAID card does this.
 
Mr Guvernment, I was in the process of making backups when this happened. But the primaries and the backups are all Areca-based RAIDs.

Whatever caused this, it did it to 3 out of 4 raid sets before I even realized it was happening. I had one pair of volumes attached, disconnected them, connected the other set (on occasion this works), but the 1882's kept beeping. So I checked to make sure that no drive lights were indicating failures (they were not). I saw that both RAIDs were operating degraded, but I could not see how to do anything about it. I switched back to the original pair, and whammo, one of these got hosed in the process. So here I sit, 3 of 4 RAID sets ganked, two now with two drives marked failed, a third with one drive so marked.

I strongly believe that isks and the data are okay, I just strngly believe I need to get the Areca controller to 'just add them back' into the arrays without reinitializing them -- at least it's worth the try. I am sure that in the case for the two-drive failure case, this is the only hope. And since the data on these volumes are matched pairs, losing one array is tantamont to losing the other array. Half the data is worthless. These files are huge, up to 300GB each (they can run into TB's per file) so copying them is not really all that trivial...

staticlag, I do not believe the Areca cards do what you describe, that they forever mark a disk as unusable. Regarding hotplugging, SAS is advertised as hot-swappable, and so are Areca arrays -- they store all RAID metadata on the RAID set drives (not the controller) exactly for this purpose. Areca said that I should be able to do what I am doing. Just to be clear, I do not plug in these arrays more than about once every few weeks. I was describing the way I use them -- as moveable/relocatable storage -- rather than in the typical RAID use-case of fixed storage always attached to the same controller, that run endlessly until disks wear themselves out.

This seems to related to the 'arcmsr' driver -- it either does not properly rescan the SAS channel when it senses a new RAID set, or it does not properly update sysfs when it does rescan. My guess is the former, since if the controller mistakes the new RAID set for the old RAID set it might assume that data has been corrupted and drop the disk from the array. When I tried a suggestion I found to get sysfs to trigger a SCSI bus rescan, this all began to happen. This should never have caused data corruption by the RAID controller since it should just command the kernel to re-read the controller for updates, which may trigger the controller to do the same. But this is not some low-level memory hack, these are standard sysfs interfaces used for this exact purpose. And I have tried this before too, and nothing bad ever happened (actually, nothing at all ever happened, but is should cause the controller to update the file system info).

But that is just a guess. That is why I think the best course is to simply get the Areca card to just "forgive" the perceived failure and add it back to the array and restart its process of recognizing the array as if nothing bad ever happened. It is such a howto that I am looking for. It seems others have been able to do this, but the way they describe doing it seems incomplete, at least as far as the version GUI I have (the CLI is worthless, it doesn't even support up-arrow command recall...)

I am looking into R-Studio now. Thank you for the suggestion. I guess I could simply power down the array, get a few empty disks and 'dd' the ones marked 'failed' by the controller. 'll just need to get a dumb SAS controller to do it with. Then at least I can experiment with a little less worry.

Thanks again, everyone, for the suggestions. Areca is trying too, but they seem more interested in asking me what I did to cause all this. Of course I don't mind explaining but there is a language barrier to contend with. And they have a 24hr turnaround with each email so it is a very torturous process, not well suited when I am under pressure to get this resolved (and to do other things too).

best always,
 
You should be able to disable oprom in the BIOS for whatever PCIe slot the RAID controller is hooked up to which would let you boot the system with the RAID connected but without trying to boot off SAS. Probably need to just delete the arrays and re-create the volumes in recovery/forced/no init/whatever mode it is where you say "here's a bunch of drives, pretend they're good".
 
-Dragon- said:
You should be able to disable oprom in the BIOS for whatever PCIe slot the RAID controller is hooked up to which would let you boot the system with the RAID connected but without trying to boot off SAS. Probably need to just delete the arrays and re-create the volumes in recovery/forced/no init/whatever mode it is where you say "here's a bunch of drives, pretend they're good".
Click to expand...

Ehh no you dont do no-init except as a last resort.

OP there are many threads on this topic, been covered to death -- suggest searching for them.
 
odditory: i have read virtually all of those posts -- and before I opened this thread. It's how I knew this was the best forum to ask for help. My Areca card has flagged two drives in a RAID5 set as 'failed', but I serously doubt that they are. The controllerjust lists the wayward disks as another RAID set of exactly trhe same name. I believe I need to override the Areca card's "fail disk" mechanism and have it start using the disk as-is. If the drives are truly bad, then so what? It *can't* hurt anything -- by definition. But if they really are good, then the RAID set will come back to life. That's my theory anyway. The trouble is that the existing posts seem to agree with me BUT the way those posts outline how to do this is not clear to me, or maybe it's that my 1882 card has a slightly different interface than the 1680's/1220's that have been 'covered to death.' If I missed a post that covers this hotplug issue, it's causes, effects, and remedies, please paste the URL -- it will help me and anyone else that finds this thread. It is not my intention or desire to be lazy. I really need some help with this.

Dragon: I believe that what you are suggesting is what I need to do. As for the booting gank, the issue is in the Linux kernel code I believe... The grub bootloader finds the right boot sector and delivers me to the grub boot menu -- but when the boot process kicks off and the pivot to the root drive occurs, the kernel is pointing to the SAS interface as hd0 and hd1 and numbers the SATA disks as hd2++. I suspect that my solution lies in Grub2 and persistent volume labels but I haven't fouond the time for that. It's just easier to hot-plug that SAS drives pst-boot when I need them (until now, that is).

But in the end, I do not believe that the post-boot-hotplug was the issue, I believe that the root cause of this problem was that I did not reboot before unplugging one RAID set and hotplugging a different one. That *ought to work, no question* but it never does. Then I tried to get sysfs to do it via the control it provides -- the interface rescan value -- but I believe that got the controller ina "funny state" and started cconfsing it and it reacted by assuming drives were bad (a driver issue). that is my theory anyway, it's the only thing that fits the fact pattern.

I have not found this issue in any previous post so if nothing else it stands as a warning to anyone who thinks they can believe Areca's claim that their RAID volumes can be hotSWAPPED (at least as of Linux 3.6.11).-- they really cannot, and pushing sysfs to rescan the volumes as a work-around is akin to running with scissors :eek: just don't do it.
 
Can you screenshot the event history page. Or better yet since your *nix can you show me:

cli64 event info
cli64 disk info
cli64 vsf info vol=1
cli64 vsf info vol=2 [probably nothing here]

I have recovered tons of areca arrays in the past.

The good news is from your screenshot where the array is failed all the disks are in order. If the disks just failed at once then it should be pretty easy to recover it back into the normal state but if they didn't fail at the same time then you you need to find out which one failed firsst (10, 15, or possibly 16) so can re-create the array and pull the disk that failed first and re-insert and let it rebuild.
 
odditory said:
Ehh no you dont do no-init except as a last resort.
Click to expand...

If you have a good event history and now what happened this is usually your best bet though. I have seen lots of times where the 'failed volume revived' function or level2scan options have completely screwed the disk order (or fail order) and messing up the array with no way to recover when someone didn't notice this and ran a fsck when it was in that state.
 
okay here goes -- thx for the advice on cli64 -- now if they would only add a scrollback buffer ;)

Here's all the data you asked for... You'll note that there are a few RAID volumes -- all of which need fixin' but the jacked one attached now is "MB2-RAID"



Date-Time Device Event Type Elapsed Time Errors
===============================================================================
2013-03-18 09:49:52 MB2-RAID Rebuild RaidSet
2013-03-18 09:49:52 MB2-RAID Rebuild RaidSet
2013-03-18 09:49:52 Enc#2 Disk-09 Device Inserted
2013-03-18 09:49:52 Enc#2 Disk-11 Device Inserted
2013-03-18 09:49:52 Enc#2 Disk-14 Device Inserted
2013-03-18 09:49:52 Enc#2 Disk-10 Device Inserted
2013-03-18 09:49:52 Enc#2 Disk-12 Device Inserted
2013-03-18 09:49:52 Enc#2 Disk-13 Device Inserted
2013-03-18 09:49:52 Enc#2 Disk-15 Device Inserted
2013-03-18 09:49:52 Enc#2 Disk-16 Device Inserted
2013-03-18 09:49:52 Enclosure#2 Added
2013-03-18 09:49:51 Enclosure#2 Removed
2013-03-18 09:49:51 Enc#2 SES2Device Device Removed
2013-03-18 09:49:50 Enc#2 Disk-09 Device Removed
2013-03-18 09:49:50 Enc#2 Disk-10 Device Removed
2013-03-18 09:49:49 Enc#2 Disk-11 Device Removed
2013-03-18 09:49:49 Enc#2 Disk-13 Device Removed
2013-03-18 09:49:49 Enc#2 Disk-14 Device Removed
2013-03-18 09:49:49 Enc#2 Disk-16 Device Removed
2013-03-18 09:49:49 MB2-RAID RaidSet Degraded
2013-03-18 09:49:49 MB2-RAID RaidSet Degraded
2013-03-18 09:49:49 Enc#2 Disk-12 Device Removed
2013-03-18 09:49:49 QRAID Volume Failed
2013-03-18 09:49:48 QRAID Volume Failed
2013-03-18 09:49:48 Enc#2 Disk-15 Device Removed
2013-03-18 09:49:48 MB2-RAID RaidSet Degraded
2013-03-18 09:49:48 QRAID Volume Failed
2013-03-18 09:47:45 MB2-RAID Rebuild RaidSet
2013-03-18 09:47:45 MB2-RAID Rebuild RaidSet
2013-03-18 09:47:45 Enc#2 Disk-14 Device Inserted
2013-03-18 09:47:45 Enc#2 Disk-13 Device Inserted
2013-03-18 09:47:43 MB2-RAID Rebuild RaidSet
2013-03-18 09:47:43 Enc#2 Disk-12 Device Inserted
2013-03-18 09:47:35 Enc#2 Disk-16 Device Inserted
2013-03-18 09:47:35 Enc#2 Disk-15 Device Inserted
2013-03-18 09:47:25 Enc#2 Disk-10 Device Inserted
2013-03-18 09:47:19 Enclosure#2 Added
2013-03-18 09:47:16 Enclosure#2 Removed
2013-03-18 09:47:16 Enc#2 SES2Device Device Removed
2013-03-18 09:47:16 Enc#2 Disk-09 Device Removed
2013-03-18 09:47:16 Enc#2 Disk-10 Device Removed
2013-03-18 09:47:15 Enc#2 Disk-11 Device Removed
2013-03-18 09:47:15 Enc#2 Disk-12 Device Removed
2013-03-18 09:47:14 Enc#2 Disk-13 Device Removed
2013-03-18 09:47:14 Enc#2 Disk-14 Device Removed
2013-03-18 09:47:14 Enc#2 Disk-15 Device Removed
2013-03-18 09:47:14 Enc#2 Disk-16 Device Removed
2013-03-18 09:38:40 MB2-RAID Offlined
2013-03-18 09:37:27 MB2-RAID Offlined
2013-03-17 19:32:16 MB2-RAID RaidSet Degraded
2013-03-17 19:32:16 QRAID Volume Failed
2013-03-17 19:32:16 MB2-RAID RaidSet Degraded
2013-03-17 19:32:16 QRAID Volume Failed
2013-03-17 19:32:16 MB2-RAID RaidSet Degraded
2013-03-17 19:32:16 QRAID Volume Failed
2013-03-17 19:32:15 MB2-RAID RaidSet Degraded
2013-03-17 19:32:15 QRAID Volume Failed
2013-03-17 19:32:15 MB2-RAID RaidSet Degraded
2013-03-17 19:32:15 QRAID Volume Failed
2013-03-17 19:32:15 MB2-RAID RaidSet Degraded
2013-03-17 19:32:15 QRAID Volume Failed
2013-03-17 19:32:14 MB2-RAID RaidSet Degraded
2013-03-17 19:32:14 QRAID Volume Degraded
2013-03-17 19:18:23 172.016.003.219 HTTP Log In
2013-03-17 19:12:08 Enc#2 Disk-09 Device Inserted
2013-03-17 19:12:08 Enc#2 Disk-10 Device Inserted
2013-03-17 19:12:08 Enc#2 Disk-12 Device Inserted
2013-03-17 19:12:08 Enc#2 Disk-11 Device Inserted
2013-03-17 19:12:08 Enc#2 Disk-13 Device Inserted
2013-03-17 19:12:08 Enc#2 Disk-15 Device Inserted
2013-03-17 19:12:08 Enc#2 Disk-14 Device Inserted
2013-03-17 19:12:08 Enc#2 Disk-16 Device Inserted
2013-03-17 19:12:08 Enclosure#2 Added
2013-03-17 19:08:32 H/W MONITOR Raid Powered On
2013-03-17 19:07:59 Enclosure#2 Removed
2013-03-17 19:07:59 Enc#2 SES2Device Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 11 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 10 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 09 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 08 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 07 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 06 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 05 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 04 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 03 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 02 Device Removed
2013-03-17 19:07:59 Enc#2 SLOT 01 Device Removed
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 MB1-RAID RaidSet Degraded
2013-03-17 19:07:59 Enc#2 SLOT 12 Device Removed
2013-03-17 19:07:59 IRAID24 Volume Failed
2013-03-17 19:07:58 IRAID24 Volume Failed
2013-03-17 19:07:58 IRAID24 Volume Failed
2013-03-17 19:07:57 IRAID24 Volume Failed
2013-03-17 19:07:57 IRAID24 Volume Failed
2013-03-17 19:07:57 IRAID24 Volume Failed
2013-03-17 19:07:56 IRAID24 Volume Failed
2013-03-17 19:07:56 IRAID24 Volume Failed
2013-03-17 19:07:56 IRAID24 Volume Failed
2013-03-17 19:07:56 IRAID24 Volume Failed
2013-03-17 19:07:56 MB1-RAID RaidSet Degraded
2013-03-17 19:07:56 IRAID24 Volume Failed
2013-03-17 19:04:49 H/W MONITOR Raid Powered On
2013-03-17 19:04:59 RS232 Terminal VT100 Log In
2013-03-17 18:53:05 MB1-RAID Rebuild RaidSet
2013-03-17 18:53:05 Enc#2 SLOT 03 Device Inserted
2013-03-17 18:52:53 Enc#2 SLOT 03 Device Removed
2013-03-17 18:52:08 MB1-RAID Rebuild RaidSet
2013-03-17 18:52:08 Enc#2 SLOT 01 Device Inserted
2013-03-17 18:51:54 Enc#2 SLOT 01 Device Removed
2013-03-17 18:51:18 172.016.003.239 HTTP Log In
2013-03-17 18:49:35 RS232 Terminal VT100 Log In
2013-03-17 18:48:49 H/W MONITOR Raid Powered On
2013-03-17 18:39:53 MB1-RAID Offlined
2013-03-17 18:36:48 172.016.003.239 HTTP Log In
2013-03-17 18:32:32 RS232 Terminal VT100 Log In
2013-03-17 18:32:07 H/W MONITOR Raid Powered On
2013-03-17 18:29:00 RS232 Terminal VT100 Log In
2013-03-17 18:28:26 H/W MONITOR Raid Powered On
2013-03-17 18:29:42 Enc#2 SLOT 07 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 01 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 09 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 10 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 02 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 11 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 05 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 03 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 08 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 06 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 04 Device Inserted
2013-03-17 18:29:42 Enc#2 SLOT 12 Device Inserted
2013-03-17 18:29:39 Enclosure#2 Added
2013-03-17 18:18:45 Enclosure#2 Removed
2013-03-17 18:18:45 Enc#2 SES2Device Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 14 Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 19 Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 18 Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 17 Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 24 Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 23 Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 22 Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 16 Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 15 Device Removed
2013-03-17 18:18:45 Enc#2 SLOT 13 Device Removed
2013-03-17 18:18:45 MB1-RAID RaidSet Degraded
2013-03-17 18:18:45 MB1-RAID RaidSet Degraded
2013-03-17 18:18:45 MB1-RAID RaidSet Degraded
2013-03-17 18:18:45 MB1-RAID RaidSet Degraded
2013-03-17 18:18:45 MB1-RAID RaidSet Degraded
2013-03-17 18:18:45 MB1-RAID RaidSet Degraded
2013-03-17 18:18:45 MB1-RAID RaidSet Degraded
2013-03-17 18:18:45 MB1-RAID RaidSet Degraded
2013-03-17 18:18:45 MB1-RAID RaidSet Degraded
2013-03-17 18:18:45 IRAID24 Volume Degraded
2013-03-17 18:18:45 Enc#2 SLOT 20 Device Removed
2013-03-17 18:18:45 IRAID24 Volume Failed
2013-03-17 18:18:44 IRAID24 Volume Failed
2013-03-17 18:18:44 IRAID24 Volume Failed
2013-03-17 18:18:43 IRAID24 Volume Failed
2013-03-17 18:18:43 IRAID24 Volume Failed
2013-03-17 18:18:43 IRAID24 Volume Failed
2013-03-17 18:18:42 Enc#2 SLOT 21 Device Removed
2013-03-17 18:18:42 IRAID24 Volume Failed
2013-03-17 18:18:42 IRAID24 Volume Failed
2013-03-17 18:18:42 MB1-RAID RaidSet Degraded
2013-03-17 18:18:42 IRAID24 Volume Failed
2013-03-17 18:09:59 172.016.003.219 HTTP Log In
2013-03-17 18:01:19 SW API Interface API Log In
2013-03-17 17:57:11 SW API Interface API Log In
2013-03-17 17:56:46 Enc#2 SLOT 13 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 23 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 24 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 16 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 18 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 21 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 17 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 20 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 15 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 19 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 22 Device Inserted
2013-03-17 17:56:46 Enc#2 SLOT 14 Device Inserted
2013-03-17 17:56:42 Enclosure#2 Added
2013-03-17 17:56:22 SW API Interface API Log In
2013-03-17 17:48:32 H/W MONITOR Raid Powered On
2013-03-17 17:50:20 Enclosure#2 Removed
2013-03-17 17:50:20 Enc#2 SES2Device Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 14 Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 19 Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 18 Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 17 Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 24 Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 23 Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 22 Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 16 Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 15 Device Removed
2013-03-17 17:50:20 Enc#2 SLOT 13 Device Removed
2013-03-17 17:50:19 MB1-RAID RaidSet Degraded
2013-03-17 17:50:19 MB1-RAID RaidSet Degraded
2013-03-17 17:50:19 MB1-RAID RaidSet Degraded
2013-03-17 17:50:19 MB1-RAID RaidSet Degraded
2013-03-17 17:50:19 MB1-RAID RaidSet Degraded
2013-03-17 17:50:19 MB1-RAID RaidSet Degraded
2013-03-17 17:50:19 MB1-RAID RaidSet Degraded
2013-03-17 17:50:19 MB1-RAID RaidSet Degraded
2013-03-17 17:50:19 MB1-RAID RaidSet Degraded
2013-03-17 17:50:19 IRAID24 Volume Degraded
2013-03-17 17:50:19 Enc#2 SLOT 20 Device Removed
2013-03-17 17:50:19 IRAID24 Volume Failed
2013-03-17 17:50:19 IRAID24 Volume Failed
2013-03-17 17:50:18 IRAID24 Volume Failed
2013-03-17 17:50:18 IRAID24 Volume Failed
2013-03-17 17:50:17 IRAID24 Volume Failed
2013-03-17 17:50:17 IRAID24 Volume Failed
2013-03-17 17:50:17 Enc#2 SLOT 21 Device Removed
2013-03-17 17:50:16 IRAID24 Volume Failed
2013-03-17 17:50:16 IRAID24 Volume Failed
2013-03-17 17:50:16 MB1-RAID RaidSet Degraded
2013-03-17 17:50:16 IRAID24 Volume Failed
2013-03-17 17:38:32 Enc#2 SLOT 19 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 17 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 14 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 15 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 13 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 20 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 22 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 23 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 18 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 24 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 16 Device Inserted
2013-03-17 17:38:32 Enc#2 SLOT 21 Device Inserted
2013-03-17 17:38:29 Enclosure#2 Added
2013-03-17 21:17:35 Enclosure#2 Removed
2013-03-17 21:17:35 Enc#2 SES2Device Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 14 Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 19 Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 18 Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 17 Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 24 Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 23 Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 22 Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 16 Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 15 Device Removed
2013-03-17 21:17:35 Enc#2 SLOT 13 Device Removed
2013-03-17 21:17:34 MB1-RAID RaidSet Degraded
2013-03-17 21:17:34 MB1-RAID RaidSet Degraded
2013-03-17 21:17:34 MB1-RAID RaidSet Degraded
2013-03-17 21:17:34 MB1-RAID RaidSet Degraded
2013-03-17 21:17:34 MB1-RAID RaidSet Degraded
===============================================================================
GuiErrMsg<0x00>: Success.
ErrMsg: Invalid Command.
# Enc# Slot# ModelName Capacity Usage
===============================================================================
1 01 Slot#1 N.A. 0.0GB N.A.
2 01 Slot#2 N.A. 0.0GB N.A.
3 01 Slot#3 N.A. 0.0GB N.A.
4 01 Slot#4 N.A. 0.0GB N.A.
5 01 Slot#5 N.A. 0.0GB N.A.
6 01 Slot#6 N.A. 0.0GB N.A.
7 01 Slot#7 N.A. 0.0GB N.A.
8 01 Slot#8 N.A. 0.0GB N.A.
9 02 Disk-01 N.A. 0.0GB N.A.
10 02 Disk-02 N.A. 0.0GB N.A.
11 02 Disk-03 N.A. 0.0GB N.A.
12 02 Disk-04 N.A. 0.0GB N.A.
13 02 Disk-05 N.A. 0.0GB N.A.
14 02 Disk-06 N.A. 0.0GB N.A.
15 02 Disk-07 N.A. 0.0GB N.A.
16 02 Disk-08 N.A. 0.0GB N.A.
17 02 Disk-09 SEAGATE ST9300603SS 300.0GB MB2-RAID
18 02 Disk-10 SEAGATE ST9300603SS 300.0GB MB2-RAID
19 02 Disk-11 SEAGATE ST9300603SS 300.0GB MB2-RAID
20 02 Disk-12 SEAGATE ST9300603SS 300.0GB MB2-RAID
21 02 Disk-13 SEAGATE ST9300603SS 300.0GB MB2-RAID
22 02 Disk-14 SEAGATE ST9300603SS 300.0GB MB2-RAID
23 02 Disk-15 SEAGATE ST9300603SS 300.0GB MB2-RAID
24 02 Disk-16 SEAGATE ST9300603SS 300.0GB MB2-RAID
===============================================================================
GuiErrMsg<0x00>: Success.
Volume Set Information
===========================================
Volume Set Name : QRAID
Raid Set Name : MB2-RAID
Volume Capacity : 2100.0GB
SCSI Ch/Id/Lun : 00/00/00
Raid Level : Raid5
Stripe Size : 64K
Member Disks : 8
Cache Mode : Write Back
Tagged Queuing : Enabled
Volume State : Failed
===========================================
GuiErrMsg<0x00>: Success.
GuiErrMsg<0x12>: No Such Device.
 
UGH -- I forgot to do the OTHER Areca card -- there are two in this machine and I don't always plug the same array in the same port: So here's the logs etc from the other controller card: :eek:

===========================================
GuiErrMsg<0x00>: Success.
GuiErrMsg<0x12>: No Such Device.
Date-Time Device Event Type Elapsed Time Errors
===============================================================================
2013-03-19 11:04:30 IRAID Complete Check 000:50:07 0
2013-03-19 10:14:23 IRAID Start Checking
2013-03-18 10:13:27 IRAID Complete Check 000:50:04 0
2013-03-18 09:23:22 IRAID Start Checking
2013-03-18 09:22:55 Enc#2 Disk-07 Device Inserted
2013-03-18 09:22:55 Enc#2 Disk-08 Device Inserted
2013-03-18 09:22:55 Enc#2 Disk-03 Device Inserted
2013-03-18 09:22:55 Enc#2 Disk-02 Device Inserted
2013-03-18 09:22:55 Enc#2 Disk-06 Device Inserted
2013-03-18 09:22:55 Enc#2 Disk-05 Device Inserted
2013-03-18 09:22:55 Enc#2 Disk-04 Device Inserted
2013-03-18 09:22:55 Enc#2 Disk-01 Device Inserted
2013-03-18 09:22:55 Enclosure#2 Added
2013-03-18 09:22:53 Enc#2 Disk-08 Device Removed
2013-03-18 09:22:52 Enc#2 Disk-07 Device Removed
2013-03-18 09:22:52 Enc#2 Disk-06 Device Removed
2013-03-18 09:22:52 Enc#2 Disk-05 Device Removed
2013-03-18 09:22:51 Enc#2 Disk-04 Device Removed
2013-03-18 09:22:51 Enc#2 Disk-03 Device Removed
2013-03-18 09:22:50 Enc#2 Disk-02 Device Removed
2013-03-18 09:22:50 Enc#2 Disk-01 Device Removed
2013-03-18 09:22:50 Enclosure#2 Removed
2013-03-18 09:22:50 Enc#2 SES2Device Device Removed
2013-03-18 09:21:16 Enc#2 Disk-01 Device Inserted
2013-03-18 09:20:58 Enc#2 Disk-06 Device Inserted
2013-03-18 09:20:50 Enc#2 Disk-04 Device Inserted
2013-03-18 09:20:50 Enc#2 Disk-05 Device Inserted
2013-03-18 09:20:48 Enclosure#2 Added
2013-03-18 09:20:46 Enclosure#2 Removed
2013-03-18 09:20:46 Enc#2 SES2Device Device Removed
2013-03-18 09:20:45 Enc#2 Disk-08 Device Removed
2013-03-18 09:20:45 Enc#2 Disk-07 Device Removed
2013-03-18 09:20:45 Enc#2 Disk-06 Device Removed
2013-03-18 09:20:44 Enc#2 Disk-05 Device Removed
2013-03-18 09:20:44 Enc#2 Disk-04 Device Removed
2013-03-18 09:20:43 Enc#2 Disk-03 Device Removed
2013-03-18 09:20:43 Enc#2 Disk-02 Device Removed
2013-03-18 09:20:43 Enc#2 Disk-01 Device Removed
2013-03-18 09:19:36 MB1-RAID Offlined
2013-03-17 22:14:58 IRAID Complete Check 003:00:43 0
2013-03-17 19:17:08 172.016.003.219 HTTP Log In
2013-03-17 19:14:14 IRAID Start Checking
2013-03-17 19:11:36 Enc#2 Disk-08 Device Inserted
2013-03-17 19:11:36 Enc#2 Disk-07 Device Inserted
2013-03-17 19:11:36 Enc#2 Disk-06 Device Inserted
2013-03-17 19:11:36 Enc#2 Disk-05 Device Inserted
2013-03-17 19:11:36 Enc#2 Disk-04 Device Inserted
2013-03-17 19:11:36 Enc#2 Disk-03 Device Inserted
2013-03-17 19:11:36 Enc#2 Disk-01 Device Inserted
2013-03-17 19:11:36 Enc#2 Disk-02 Device Inserted
2013-03-17 19:11:36 Enclosure#2 Added
2013-03-17 19:08:34 H/W MONITOR Raid Powered On
2013-03-17 19:07:38 Enclosure#2 Removed
2013-03-17 19:07:38 Enc#2 SES2Device Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 14 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 19 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 18 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 17 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 24 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 23 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 22 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 21 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 16 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 15 Device Removed
2013-03-17 19:07:38 Enc#2 SLOT 13 Device Removed
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 MB1-RAID RaidSet Degraded
2013-03-17 19:07:37 IRAID24 Volume Degraded
2013-03-17 19:07:37 Enc#2 SLOT 20 Device Removed
2013-03-17 19:07:37 IRAID24 Volume Failed
2013-03-17 19:07:36 IRAID24 Volume Failed
2013-03-17 19:07:36 IRAID24 Volume Failed
2013-03-17 19:07:36 IRAID24 Volume Failed
2013-03-17 19:07:35 IRAID24 Volume Failed
2013-03-17 19:07:35 IRAID24 Volume Failed
2013-03-17 19:07:34 IRAID24 Volume Failed
2013-03-17 19:07:34 IRAID24 Volume Failed
2013-03-17 19:07:34 IRAID24 Volume Failed
2013-03-17 19:07:34 MB1-RAID RaidSet Degraded
2013-03-17 19:07:34 IRAID24 Volume Failed
2013-03-17 19:04:51 H/W MONITOR Raid Powered On
2013-03-17 19:03:55 RS232 Terminal VT100 Log In
2013-03-17 18:50:10 172.016.003.239 HTTP Log In
2013-03-17 18:49:08 RS232 Terminal VT100 Log In
2013-03-17 18:48:51 H/W MONITOR Raid Powered On
2013-03-17 18:46:13 MB1-RAID Rebuild RaidSet
2013-03-17 18:46:12 Enc#2 SLOT 21 Device Inserted
2013-03-17 18:46:06 Enc#2 SLOT 21 Device Removed
2013-03-17 18:40:51 172.016.003.239 HTTP Log In
2013-03-17 18:32:36 RS232 Terminal VT100 Log In
2013-03-17 18:32:06 H/W MONITOR Raid Powered On
2013-03-17 18:30:33 RS232 Terminal VT100 Log In
2013-03-17 18:28:27 H/W MONITOR Raid Powered On
2013-03-17 18:25:08 Enc#2 SLOT 18 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 24 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 23 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 22 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 17 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 20 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 19 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 14 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 13 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 21 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 15 Device Inserted
2013-03-17 18:25:08 Enc#2 SLOT 16 Device Inserted
2013-03-17 18:25:07 Enclosure#2 Added
2013-03-17 18:15:25 Enclosure#2 Removed
2013-03-17 18:15:25 Enc#2 SES2Device Device Removed
2013-03-17 18:15:25 Enc#2 SLOT 11 Device Removed
2013-03-17 18:15:25 Enc#2 SLOT 10 Device Removed
2013-03-17 18:15:25 Enc#2 SLOT 09 Device Removed
2013-03-17 18:15:25 Enc#2 SLOT 08 Device Removed
2013-03-17 18:15:25 Enc#2 SLOT 07 Device Removed
2013-03-17 18:15:25 Enc#2 SLOT 06 Device Removed
2013-03-17 18:15:25 Enc#2 SLOT 05 Device Removed
2013-03-17 18:15:25 Enc#2 SLOT 04 Device Removed
2013-03-17 18:15:25 Enc#2 SLOT 02 Device Removed
2013-03-17 18:15:24 MB1-RAID RaidSet Degraded
2013-03-17 18:15:24 MB1-RAID RaidSet Degraded
2013-03-17 18:15:24 MB1-RAID RaidSet Degraded
2013-03-17 18:15:24 MB1-RAID RaidSet Degraded
2013-03-17 18:15:24 MB1-RAID RaidSet Degraded
2013-03-17 18:15:24 MB1-RAID RaidSet Degraded
2013-03-17 18:15:24 MB1-RAID RaidSet Degraded
2013-03-17 18:15:24 MB1-RAID RaidSet Degraded
2013-03-17 18:15:24 Enc#2 SLOT 12 Device Removed
2013-03-17 18:15:24 IRAID24 Volume Failed
2013-03-17 18:15:24 IRAID24 Volume Failed
2013-03-17 18:15:23 IRAID24 Volume Failed
2013-03-17 18:15:23 IRAID24 Volume Failed
2013-03-17 18:15:22 IRAID24 Volume Failed
2013-03-17 18:15:22 IRAID24 Volume Failed
2013-03-17 18:15:22 IRAID24 Volume Failed
2013-03-17 18:15:21 IRAID24 Volume Failed
2013-03-17 18:15:21 Enc#2 SLOT 03 Device Removed
2013-03-17 18:15:21 MB1-RAID RaidSet Degraded
2013-03-17 18:15:21 IRAID24 Volume Failed
2013-03-17 18:15:21 Enc#2 SLOT 01 Device Removed
2013-03-17 18:08:17 172.016.003.219 HTTP Log In
2013-03-17 18:00:07 SW API Interface API Log In
2013-03-17 17:56:47 SW API Interface API Log In
2013-03-17 17:55:46 Enc#2 SLOT 12 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 03 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 01 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 02 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 06 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 05 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 09 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 07 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 08 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 11 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 04 Device Inserted
2013-03-17 17:55:45 Enc#2 SLOT 10 Device Inserted
2013-03-17 17:55:45 Enclosure#2 Added
2013-03-17 17:48:35 H/W MONITOR Raid Powered On
2013-03-17 17:45:16 SW API Interface API Log In
2013-03-17 17:44:59 Enc#3 SES2Device Time Out Error
2013-03-17 17:44:51 Enc#2 Disk-10 Device Removed
2013-03-17 17:44:51 Enc#2 Disk-11 Device Removed
2013-03-17 17:44:51 Enc#2 Disk-12 Device Removed
2013-03-17 17:44:51 Enc#2 Disk-13 Device Removed
2013-03-17 17:44:51 Enc#2 Disk-14 Device Removed
2013-03-17 17:44:51 Enc#2 Disk-15 Device Removed
2013-03-17 17:44:51 Enc#2 SES2Device Device Removed
2013-03-17 17:44:51 Enc#2 Disk-09 Device Removed
2013-03-17 17:44:51 MB2-RAID RaidSet Degraded
2013-03-17 17:44:51 QRAID Volume Failed
2013-03-17 17:44:51 MB2-RAID RaidSet Degraded
2013-03-17 17:44:51 QRAID Volume Failed
2013-03-17 17:44:51 MB2-RAID RaidSet Degraded
2013-03-17 17:44:51 QRAID Volume Failed
2013-03-17 17:44:51 MB2-RAID RaidSet Degraded
2013-03-17 17:44:51 QRAID Volume Failed
2013-03-17 17:44:51 MB2-RAID RaidSet Degraded
2013-03-17 17:44:51 QRAID Volume Failed
2013-03-17 17:44:51 MB2-RAID RaidSet Degraded
2013-03-17 17:44:51 QRAID Volume Failed
2013-03-17 17:44:51 Enc#2 Disk-16 Device Removed
2013-03-17 17:28:05 SW API Interface API Log In
2013-03-17 17:04:14 Enc#2 Disk-09 Device Inserted
2013-03-17 17:04:14 Enc#2 Disk-10 Device Inserted
2013-03-17 17:04:14 Enc#2 Disk-11 Device Inserted
2013-03-17 17:04:14 Enc#2 Disk-12 Device Inserted
2013-03-17 17:04:14 Enc#2 Disk-13 Device Inserted
2013-03-17 17:04:14 Enc#2 Disk-14 Device Inserted
2013-03-17 17:04:14 Enc#2 Disk-15 Device Inserted
2013-03-17 17:04:14 Enc#2 Disk-16 Device Inserted
2013-03-17 17:04:13 Enclosure#2 Added
2013-03-17 17:04:06 Enclosure#2 Removed
2013-03-17 17:04:06 Enc#2 SES2Device Device Removed
2013-03-17 17:04:06 Enc#2 SLOT 11 Device Removed
2013-03-17 17:04:06 Enc#2 SLOT 10 Device Removed
2013-03-17 17:04:06 Enc#2 SLOT 09 Device Removed
2013-03-17 17:04:06 Enc#2 SLOT 08 Device Removed
2013-03-17 17:04:06 Enc#2 SLOT 07 Device Removed
2013-03-17 17:04:06 Enc#2 SLOT 06 Device Removed
2013-03-17 17:04:06 Enc#2 SLOT 05 Device Removed
2013-03-17 17:04:06 Enc#2 SLOT 04 Device Removed
2013-03-17 17:04:06 Enc#2 SLOT 02 Device Removed
2013-03-17 17:04:05 MB1-RAID RaidSet Degraded
2013-03-17 17:04:05 MB1-RAID RaidSet Degraded
2013-03-17 17:04:05 MB1-RAID RaidSet Degraded
2013-03-17 17:04:05 MB1-RAID RaidSet Degraded
2013-03-17 17:04:05 MB1-RAID RaidSet Degraded
2013-03-17 17:04:05 MB1-RAID RaidSet Degraded
2013-03-17 17:04:05 MB1-RAID RaidSet Degraded
2013-03-17 17:04:05 MB1-RAID RaidSet Degraded
2013-03-17 17:04:05 Enc#2 SLOT 12 Device Removed
2013-03-17 17:04:05 IRAID24 Volume Failed
2013-03-17 17:04:05 IRAID24 Volume Failed
2013-03-17 17:04:04 IRAID24 Volume Failed
2013-03-17 17:04:04 IRAID24 Volume Failed
2013-03-17 17:04:03 IRAID24 Volume Failed
2013-03-17 17:04:03 IRAID24 Volume Failed
2013-03-17 17:04:03 IRAID24 Volume Failed
2013-03-17 17:04:02 IRAID24 Volume Failed
2013-03-17 17:04:02 Enc#2 SLOT 03 Device Removed
2013-03-17 17:04:02 MB1-RAID RaidSet Degraded
2013-03-17 17:04:02 IRAID24 Volume Failed
2013-03-17 17:04:02 Enc#2 SLOT 01 Device Removed
2013-03-17 17:02:53 MB1-RAID Rebuild RaidSet
2013-03-17 17:02:53 MB1-RAID Rebuild RaidSet
2013-03-17 17:02:53 MB1-RAID Rebuild RaidSet
2013-03-17 17:02:53 MB1-RAID Rebuild RaidSet
2013-03-17 17:02:53 MB1-RAID Rebuild RaidSet
2013-03-17 17:02:53 Enc#2 SLOT 10 Device Inserted
2013-03-17 17:02:53 Enc#2 SLOT 11 Device Inserted
2013-03-17 17:02:53 Enc#2 SLOT 09 Device Inserted
2013-03-17 17:02:53 Enc#2 SLOT 08 Device Inserted
2013-03-17 17:02:53 Enc#2 SLOT 12 Device Inserted
2013-03-17 17:02:53 Enc#2 SLOT 14 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 20 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 19 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 18 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 17 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 24 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 23 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 22 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 16 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 15 Device Removed
2013-03-17 17:02:53 Enc#2 SLOT 13 Device Removed
2013-03-17 17:02:52 MB1-RAID RaidSet Degraded
2013-03-17 17:02:52 MB1-RAID RaidSet Degraded
2013-03-17 17:02:52 MB1-RAID RaidSet Degraded
2013-03-17 17:02:52 MB1-RAID RaidSet Degraded
2013-03-17 17:02:52 MB1-RAID RaidSet Degraded
2013-03-17 17:02:52 MB1-RAID RaidSet Degraded
2013-03-17 17:02:52 MB1-RAID RaidSet Degraded
===============================================================================
GuiErrMsg<0x00>: Success.
# Enc# Slot# ModelName Capacity Usage
===============================================================================
1 01 Slot#1 N.A. 0.0GB N.A.
2 01 Slot#2 N.A. 0.0GB N.A.
3 01 Slot#3 N.A. 0.0GB N.A.
4 01 Slot#4 N.A. 0.0GB N.A.
5 01 Slot#5 N.A. 0.0GB N.A.
6 01 Slot#6 N.A. 0.0GB N.A.
7 01 Slot#7 N.A. 0.0GB N.A.
8 01 Slot#8 N.A. 0.0GB N.A.
9 02 Disk-01 SEAGATE ST9300603SS 300.0GB MB1-RAID
10 02 Disk-02 SEAGATE ST9300603SS 300.0GB MB1-RAID
11 02 Disk-03 SEAGATE ST9300603SS 300.0GB MB1-RAID
12 02 Disk-04 SEAGATE ST9300603SS 300.0GB MB1-RAID
13 02 Disk-05 SEAGATE ST9300603SS 300.0GB MB1-RAID
14 02 Disk-06 SEAGATE ST9300603SS 300.0GB MB1-RAID
15 02 Disk-07 SEAGATE ST9300603SS 300.0GB MB1-RAID
16 02 Disk-08 SEAGATE ST9300603SS 300.0GB MB1-RAID
17 02 Disk-09 N.A. 0.0GB N.A.
18 02 Disk-10 N.A. 0.0GB N.A.
19 02 Disk-11 N.A. 0.0GB N.A.
20 02 Disk-12 N.A. 0.0GB N.A.
21 02 Disk-13 N.A. 0.0GB N.A.
22 02 Disk-14 N.A. 0.0GB N.A.
23 02 Disk-15 N.A. 0.0GB N.A.
24 02 Disk-16 N.A. 0.0GB N.A.
===============================================================================
GuiErrMsg<0x00>: Success.
Volume Set Information
===========================================
Volume Set Name : IRAID
Raid Set Name : MB1-RAID
Volume Capacity : 2100.0GB
SCSI Ch/Id/Lun : 00/00/00
Raid Level : Raid5
Stripe Size : 64K
Member Disks : 8
Cache Mode : Write Back
Tagged Queuing : Enabled
Volume State : Normal
===========================================
GuiErrMsg<0x00>: Success.
GuiErrMsg<0x12>: No Such Device.[/FONT]
 
Capt.Frito said:
okay here goes -- thx for the advice on cli64 -- now if they would only add a scrollback buffer ;)

Here's all the data you asked for... You'll note that there are a few RAID volumes -- all of which need fixin' but the jacked one attached now is "MB2-RAID"
Click to expand...

Well unfortunately it looks liek the buffer only goes back a day or two probably due to the constant removal/insertion of the drives a bunch of times =(

The optimal situation would be to have the event history from when the array first failed (the first time) which appears to not be available.

I assume the 'View events/mute beeper' in the web-interface doesn't give anymore right?

It also looks like you were disconnecting/connecting the enclosure was not offlined first? If you were doing that it would fail the array every time you disconnected it and is generally a 'nono'.

If you are absolutely sure the array was in a normal state before all this happened and the device has not been mounted since I would:

Delete the current raid sets.

Re-create the raid set.

When creating the volume set be sure to make sure its 2100.0 GB, raid5, stripe size 64k and for init mode chose:

'no init (rescuie)

This should get your array back to its original state.

After that I would make sure nothing is going to try to mount the fs in ro mode without doing any writes to the fs (this may be tricky depending on what FS your using as ext3/ext4 will still try to replay/reload the journal even if you mount in RO) and then see if you can access the data without any input/output errors in directories and/or check the data against known md5 hashes (if md5/crc hashes are available of any of the files you have).

If that checks out ok I would probably still backup all the files to another drive and then if you were ready to re-use the array again I would do a check on the array to see if it finds any inconsistencies in the data (only after its been backed up).

The problem could be that one of the disks was failed degrading the array (before it was completely failed) and it ran for a while in a degraded state which means data would be inconsistent on one of the drives. You really don't want to have that disk in the array. If you know which disk it was you could pull it out after you re-create with no-init (rescue) mode to get it in a consistent state but from your event history its hard to know which drive actually failed first as its truncated =(
 
Okay -- this all sounds reasonable. the GUI shows the same history, no more.

A few questions before I take the plunge...!

1. So, I should have been setting the array to "offline" state before disconnecting it each time? If so, I had no idea... If I should have, I will from now on -- color me 'rehabilitated'.

2. I just grabbed a copy of R-Studio -- it runs in Linux, always like to support the cause, and it looked like a decent tool to have, regardless.

....The point is that it can image each drive -- should I do that first, perhaps? Not sure how it differs from good-'ol dd in this regard, or how to get the Areca controller to let me do it -- (maybe I could after I delete the RAID set but before the rescue...) Thoughts?

3. The file system is NTFS, the XP/4K block size kind (not sure which winrev that is)

4. I use ntfs-3g drivers, but I am sure I can mount -ro the volume... is that what you mean?

5. I normally use ReiserFS in Linux, always have. I wish I had here too, but the whole reason to have this mess in the first place is to use with a high-speed digital I/Q recorder that was built on WindowsXP (for some reason -- and the raid volume names probably make more sense to you now). The company has since moved to embedded Linux, so hopefully this migration will be the last of it.. Ironic that it should choose this moment to blow sky high! Probably some evil plan hatched by M$

Anyway, I'll take action as soon I hear back on the image thing...
 
Capt.Frito said:
1. So, I should have been setting the array to "offline" state before disconnecting it each time? If so, I had no idea... If I should have, I will from now on -- color me 'rehabilitated'.
Click to expand...

Yes. You should never disconnect the enclosure when the array is still active. That is why you get the beeping because you are essentially failing the array and you can get in the situation you are in now. If you first Offline the raid set (which will immediately make the block device inaccessible to the OS) you should be able to safely remove the disks without worrying about the array becoming degraded or failed.

That is pretty much the point of that feature. Otherwise the controller doesn't know the difference of a drive failing (going away) or just being removed to be replaced and treats it like a normal drive failure.

Capt.Frito said:
2. I just grabbed a copy of R-Studio -- it runs in Linux, always like to support the cause, and it looked like a decent tool to have, regardless.

....The point is that it can image each drive -- should I do that first, perhaps? Not sure how it differs from good-'ol dd in this regard, or how to get the Areca controller to let me do it -- (maybe I could after I delete the RAID set but before the rescue...) Thoughts?
Click to expand...

I would definitely be looking at using that if you are not able to get the other methods working. You can also just use dd. You can use the areca controller if you delete the raid set and set all the disks into pass through or change the 'RAID MODE" to JBOD mode (again after deleting the raid set). Keep in mind this does wipe out the metadata of the array (what the disk order, raid type, stripe size, etc...). Now since you already know all that information its not that big of a deal. If you want to just make a backup image of all the drives then regular old dd should work fine with a non-raid SAS controller or putting the controller in JBOD mode but again you will lose the array metadata if you do it on the areca controller.

Capt.Frito said:
3. The file system is NTFS, the XP/4K block size kind (not sure which winrev that is)
Click to expand...

Ok in that case I would just go ahead and avoid ntfs-3g and use the actual old deprecated read-only 'ntfs' driver. AFAIK that one never supported writing so you can be sure it wont do anything to the FS if you use that one.

Capt.Frito said:
4. I use ntfs-3g drivers, but I am sure I can mount -ro the volume... is that what you mean?
Click to expand...

Again I don't know how much I would trust the ntfs-3g driver (well more than I would on windows). I would stick to just the regular 'ntfs' read-only driver.

Capt.Frito said:
5. I normally use ReiserFS in Linux, always have. I wish I had here too, but the whole reason to have this mess in the first place is to use with a high-speed digital I/Q recorder that was built on WindowsXP (for some reason -- and the raid volume names probably make more sense to you now). The company has since moved to embedded Linux, so hopefully this migration will be the last of it.. Ironic that it should choose this moment to blow sky high! Probably some evil plan hatched by M$

Anyway, I'll take action as soon I hear back on the image thing...
Click to expand...

Was wondering why it was NTFS =P. Good luck. Some good things to know in the future are that you should always check the event history if you ever hear beeping of any kind to see wtf is up. If the array ever fails like this in the future again you should check the event history (and save somewhere) so it doesn't get polluted by all the drives going in/out where you run out of buffer.

I am sure every time you disconnected the array before the controller went ape shit and started beeping. If you offline the array first that will not happen.
 
If you just want to have backups you could just throw a 3TB drive in it and dd each 300GB drive to its own file (no need to get 6 300GB files since you could just dd back if something happened), since its a raw block level dump file system is irrelevant. Another thing you might want to do in order to keep from losing events in the future is setup a SMTP account to receive all the events (since for whatever reason areca thinks it's cool to spam your inbox but can't be bothered to provide proper syslog support, then again neither does adaptec, not sure about lsi)
 
Okay all the help is great, here I go...

Just for the record, I was not removing individual disk drives, but disconnecting the array box -- all 16 drives -- entirely in one shot from the controller via the external SF8088 cable. I am not defending anything I just want to make sure the perception is accurate for those that benefit from this post in the future. :D

I see now that I had been living on borrowed time but I fugured umounting the thing was enough. Obviously not. I will report back on how it all goes.

You guys are really great!
 
Capt.Frito said:
Okay all the help is great, here I go...

Just for the record, I was not removing individual disk drives, but disconnecting the array box -- all 16 drives -- entirely in one shot from the controller via the external SF8088 cable. I am not defending anything I just want to make sure the perception is accurate for those that benefit from this post in the future. :D

I see now that I had been living on borrowed time but I fugured umounting the thing was enough. Obviously not. I will report back on how it all goes.

You guys are really great!
Click to expand...

Yeah I understood the situation. Offlining the raidset is like doing an unmount on the controller side of things. The controller sometimes to be smart enough to revive the array when all the disks went away at once but not always. Either way your going to have the array be in the 'failed' state on the controller from disconnecting everything at once.

Looks like you know not to do that in the future.

I would think your boot issue would be easy to work around so you don't have to do that though.
 
houkouonchi said:
If you have a good event history and now what happened this is usually your best bet though. I have seen lots of times where the 'failed volume revived' function or level2scan options have completely screwed the disk order (or fail order) and messing up the array with no way to recover when someone didn't notice this and ran a fsck when it was in that state.
Click to expand...

And I've seen many people in a panic that did a no-init recreate and it turned out their drives weren't in the original order and they made a bad situation worse by blowing away the partial meta that existed on the partial set of disks still reporting as being in a raidset - and had they not done that they still would've had a reference to document the volume info. I didnt have enough time earlier to make a long post but was hoping to save OP this heartache since someone had posted 'try this' like its no big deal, without underlining it as the nuclear option only to be exercised assuming A) you know drives are in original order, B) you've documented original raidset parameters - LBA/raidlevel/stripesize, C) optional but ideally you've also dumped raw images of every disk

And @OP, no, this procedure isnt different between 1680/1880/1882 cards - they run the same block pattern and meta scheme.

Most important thing is to take these failure situations slow. Also make sure "Hot Plugged Disk For Rebuilding" is set to disabled so the controller isnt attempting to auto-rebuild while you're working through these recovery steps. Ive seen this screw people over where they recreate with no-init, disks are in wrong order, and controller starts auto-rebuilding with these disks in the wrong order -- effectively killing their good data by overwriting it with garbage much to the same effect of a zero fill.
 
Last edited:
Well, sadly, it didn't work, at least it doesn't seem like it. When I mounted the array I didn't specify a filesystem type; mount didn't complain so I can only assume it figured it out that it was NTFS but when I tried any reads (ls for example) it just reported I/O error. Not sure if that leaves room for hope, but I'm thinking not. Just in case there is I unmounted it (after deactivating it) and powered the array box down.

But never fear, I have two more that need to be fixed, same issues, same causes, same controller cards, so let's assume that there are no log histories to go from.

So -- I have ordered a non-raid LSI SAS interface card so I can image the drives one-by-one without blowing away the metadata using R-Studio. This array is built on twelve 2.5" 600G WD RE's (RAID5 w/o spare -- again, hat's off to the winstrument maker) and it was about 1/2 full befiore the dark times hit.

That other 24disk SansDigital enclosure -- divided into two 12-disk RAID sets -- is powered down at the moment and will stay that way until I understand how to recover the metadata and make sure that the raid gets reconstructed correctly (if at all possible).

So as not to recreate the wheel: odditory is there a post you can direct me to that outlines how to do this? And please try to understand that I don't have any long-running experience with the Areca product family (I have never had any such problem with my ages-old 3ware cards or Adaptec SCSI cards) so I don't know what to expect, what is the same, what is different, etc.

houkouonchi -- i cannot find a switch in BIOS that disables loading boot roms from add-in cards, just a few that turn off built-in peripherals like PXE and the onboard Intel RAID ROM (which was already off). Anything else I should look at?

BTW I used blockdev --setro /dev/sde1 (in my specific case and then used mount -o ro,noload /dev/sde1 to block ioctl from attempting any writes when I checked the array.

You guys are still the best in my book. I am grateful for all the help.
 
First, if you haven't already contacted Areca support (support (at) areca.com.tw) , then send them an email, limit the message (4 or 5 sentences max, keep it simple, they dont need all the background in the OP) and attach the screenshot you posted in the OP - your first link to the jpg showing the jumbled drives. The point here is that they be harassed when this problem occurs so there's more pressure on them to refine the logic to be more resilient. When their tech support burden is alleviated by "peer to peer" support on forums they wont hear about it and less fire under their asses.

That said, for me, the normal escalation order in a "jumbled drive" scenario is the following:

1) Make sure "Hot Plugged Disk For Rebuilding" is set to Disabled so the controller doesn't decide on its own to auto-rebuild a partial set of disks (or disks in the wrong order) and wreck your chances of recovery

2) RESCUE keyword "Raidset Functions -> Rescue Radiset" and reboot. If the volume isn't whole again or all the drives aren't back in a single raidset, and if for some reason I didn't have a backup, then

3) Dump image of every disk with RStudio to spare disks (select No Compression. The reason being so they could be analyzed in a hex editor later if expert data recovery was the last resort)

4) Enter boot-time BIOS of areca controller, go to volume information and document the drive order of the volume, strip size, raid level, LBA translation type, etc.

5) The next step would either be a level2rescue or no-init, depending on who you ask. Areca states to contact them first prior to a level2rescue, because they state it only applies to certain cases (though they've never really detailed what those special cases are). I think they say that because level2rescue, when it cannot find good meta, attempts a best-guess at what the original volume parameters were, or takes partial meta and attempts to fill in the blanks. As houkouonchi alluded to, level2rescue can make mistakes in its best-guessing, and in the event someone runs a file system check without specifying read-only, data loss may occur when it starts fixing errors that don't actually exist but detected as such due to wrong volume parameters or drive order. Personally I've never had a problem with level2rescue, and both RESCUE and LeVeL2ReScUe are read-only operations, meaning they do not commit any changes to disk, it's only active until the next reboot. To make the meta stick you'd need the SIGNAT command, but you only perform that when you're 100% that the meta/volume is correct and volume is accessible to your satisfaction (testing large files, read-only filesystem check, etc).

6) If level2rescue doesnt put the jumbled drives back into a single raidset/volume then NO-INIT is the last resort and dependent on the volume parameters you documented.

And if a NO-INIT recreate doesnt produce an accessible volume then there are still ways to recover the data with R-Studio and the Areca placed into JBOD mode but thats a whole new discussion.
 
Last edited:
1) Make sure "Hot Plugged Disk For Rebuilding" is set to Disabled so the controller doesn't decide on its own to auto-rebuild a partial set of disks (or disks in the wrong order) and wreck your chances of recovery
Click to expand...

I cannot find any such option, not in the web gui anyway. The closest thing I found was System Controls->System Configuration->Auto Activate Incomplete Raid [enabled]

Should this be [disabled]?

Also, I did contact Areca prior to my posts here. In the end, they just said it was all my fault and there wasn't much they could do.

If I knew exactly what was necessary to know, I'd post only those things. But I don't so I have been disclosing everything.

One other tidbit: Even if I "offline" the RAID set, unplugging the SF8088 cable will still cause the 1882 card to squawk madly. It must sense the "disappearance" of the enclosure's SAS expander given that "offlining" causes the individual disks to power down nearly immediately.

As I mentioened I have two other arrays that are in the same shape -- two failed disks each in a RAID5 (all frm the same 5min episode). I will undertake imaging the disks using R-Studio and report back in when one set is ready for action.

Thank you again everyone for your help and patience.
 
Last edited:
Does anyone know if there is a problem using two Areca 1882's in the same server? I could never get a straight answer out of Areca on this. I asked again since this starting happeneing, but no response yet, not even to this simple question...
 
I used the boot-level controller interface. I recovered this bit of information: Member Disk Channels:
.e2s14.e2s22.e2s17.e2s19.e2s20.e2s15.e2s18.e2s16.e2s24.e2s13.e2s23.e2s25.

What does this mean exactly and is it useful in reconstructing things? (this was taken from one of the other two 12-disk RAID5's that tanked)

The other one reported
.e2s5.e2s12.e2s8.e2s9.e2s11.e2s6.e2s10.e2s7.e2s1.e2s2.e2s3.e2s4.
 
I sent a one-liner question to Areca Tech Support asking if it is okay to have more than one 1882ix controller per server (Linux 3.6.11 w/arcmsr kernel driver) ... three times now ... still no answer :(

Does anyone know? I am wondering if this is part of the RAID5 scrambling issue...
 
Multile cards is fine, I run dual 1882's. Your jumbled drive issue is from unplugging live arrays repeatedly but you know that now.
 
Last edited:
Yes you are correct -- I now know that I shouldn't hotplug these enclosures. I guess I was lamenting that my logs were screwy because I use these arrays as "movable storage" out of necessity.

So I am about to try recovery via R-Tools, but I am still largely in the drk on all this. One thing that R-TT is telling me is that I need to know block order =-- this is something that I am used to seeng when I've set of Linx software raid, but I can't find it in Areca's settings or output anywhere...?

I just received my LSI 9207-4i4e non-RAID HBA so I can see/image the disks directly and (hopefully) not rewrite any metadata. All these disks are SAS -- hopefully this is a good idea

Here's what I have so far -- is there something else I need before I can begin? (besides experience)


for card "FBDF0000h":
Volume Set Information
Volume Set Name = IRAID24
Raid Set Name = MB1-RAID
Capacity = 6600.0GB
Volume State = Failed
SCSI/ID/LUN: = 0/0/0
Raid Level = 5
Stripe Size = 64KB
Block Size = 4096Bytes
Member Disks = 12
Cache Attribute = Write Back
Tag Queuing = Enabled

RAID Set Information
MB1-RAID : 12/12 Disks : Degraded
Raid Set Name = MB1-RAID
Member Disks = 12
Raid State = normal
RAID Power State = Operating
Total Capacity = 7200.0GB
Free Capacity = 0.0GB
Min Member Disk Size = 600GB
Supported Volumes = 128
Member Disk Channels = .e2s14.e2s22.e2s17.e2s19.e2s20.e2s15.e2s18.e2s16.e2s24.e2s13.e2s23.e2s25.

for card "FBBF0000h":
Volume Set Information
Volume Set Name = IRAID24
Raid Set Name = MB1-RAID
Capacity = 6600.0GB
Volume State = Failed
SCSI/ID/LUN: = 0/0/0
Raid Level = 5
Stripe Size = 64KB
Block Size = 4096Bytes
Member Disks = 12
Cache Attribute = Write Back
Write Protection = Disabled
Tag Queuing = Enabled

RAID Set Information
MB1-RAID : 12/12 Disks : Normal
Raid Set Name = MB1-RAID
Member Disks = 12
Raid State = normal
RAID Power State = Normal
Total Capacity = 7200.0GB
Free Capacity = 0.0GB
Min Member Disk Size = 600GB
Supported Volumes = 128
Member Disk Channels = .e2s5.e2s12.e2s8.e2s9.e2s11.e2s6.e2s10.e2s7.e2s1.e2s2.e2s3.e 2s4
 
In the end, I am still in need of some instruction on how to determine the original member disk order because the 1882's logs are not complete enough to show it. I have R-Tools and I have a non-RAID SAS HBA at my disposal. The OS is Linux. there are two RAID5 arrays that came up out of order because I did not use the 1882's "offline array" function before disconnecting them :eek:. I have entered a 12-step program for my errant behavior, but my arrays are still out of order.

Please help if you can with the "howto" part...


In other news, I finally received some replies from Areca. I keep asking how to determine the orignal boot order, they keep answering with this

>> these drives are out of order in raidset information page, if out of order is caused by drive online remove/insert.
>>the only possible way to recover these volumes is reconstruct new raidset and volume with original settings.
>> reconstruct raidset and volume mean create new raidset and volume but the volume initialization mode must be no init for rescue to keep the data in volume.
>> reconstructed configurations works only if these drives been created with correct order and the volume configuration is identical as original one. you can refer the current volume information page to make sure you create the new volume with correct setting.
Click to expand...

Of course, by now I understand WHAT to do, just not HOW to do it. It's the HOW part I am asking for help with.

For example, when I load R-Tools using the Areca 1882 as the HBA, it only shows me the RAID array, not the individual disks. I don't think that is what I need. I did get a new LSI HBA that is not a RAID card to be able to see the disks directly, because someone said switching the Areca card to JBOD mode makes it wipe out any RAID metadata, but I haven't tried it yet, because I still don't know what I am looking for. At this point I have no idea if that is true or not, or even if it matters. *sigh*

Then I asked about how to properly CONNECT volumes post-boot, because there is no way to tell the BIOS in this machine not to enumerate the plug-in card disks ahead of the permanently mounted SATA disks. They answered with this regarding DISCONNECT:

>> if you would like to remove array member drivesfrom a running server, please off line the raidset before disconnect them.
Click to expand...

They did finally reply with one useful answer:

>> yes, the linux driver certified to handle multiple cards.
Click to expand...

Anyway, you folks here have been very patient. Hopefully I have not worn out my welcome.
 
If you plug the disks into the LSI HBA, you should still be able to access them with R-Studio.

There is no easy or quick way to do it. You will have to try every possible combination unless you have some clues to start from with your old card. Try in the order they are listed in the interface, if that doesn't work try different variations of the order. You will also need to guess block sizes. R-studio is pretty powerful but you can expect some to quite a bit of trial and error.
 
About 4 years ago I actually had to do that on linux software raid6 with 10 hard drives when more than 3 drives were kicked out of an array at the same time + UREs were involved. I think I needed 12 iterations to find the correct drive order. Good thing I was able to force the raid to create (assume clean) + read only and mount the filesystems as read only. Since then I keep records of what drives are in what order on all arrays.
 
Can you back up three steps and confirm that you attempted the RESCUE keyword in Rescue Raidset? If so what happened? Did you read through my previous message? However if you've already attempted a NO-INIT recreate then it would save time to state that since then the rescue keywords are useless as the meta would've been rewritten.

As for Areca support's response, assuming it was from Kevin and not someone new, I'm not sure why they're telling you "the only possible way to recovery" is with the NO-INIT process, because I've fixed this precise issue plenty of times with rescue and/or level2rescue.

Lastly: How time sensitive is recovery? Does it make a difference if it takes a day or a week or more? Is this business critical? You *will* get your data back if you have patience.
 
Last edited:
From your web interface screenshots on the first page the disks were already in the same physical/logical order. Order should not be a problem.
 
@houkouonchi

This is something that has peeved me with RAID subsystems; technically, even if drives get moved around it shouldn't matter. Drives these days have UUIDs and Worldwide Names. By rights, there should be enough information to stamp a "write order" into the metadata so that even if a drive gets moved to another physical port, writing and recovery should be unaffected.

I fell victim to this with md RAID; I had moved some drives around and for some reason mdadm marked every drive as being a spare. During the restoration attempt I screwed up and ended up blowing away the array. Highly annoying.
 
I am really glad I saw this as I have a similar setup. Is there a workaround to having to "hot plug" an array?

I have a Server with a 1880x card that is connected to a Supermicro SC847-JBOD chassis. Because the Supermicro chassis is so loud, I only turn it on when I need to access the array. I think this is similar to "hot plugging" since the Server is generally already running when I turn on the Supermicro chassis.

My experience with this setup is that the array will generally show up in windows if my Areca card is running 1.49 firmware. When I upgraded to 1.51, it never shows up unless I power down the Server, turn on the Supermicro chassis, and then power up the server again.

Does anyone have a similar setup and know a workaround? Ideally, I would like to leave the Server on and power up and down the Supermicro chassis as needed.

P.S. I hope OP get his files back. Good luck.
 
parityboy said:
@houkouonchi

This is something that has peeved me with RAID subsystems; technically, even if drives get moved around it shouldn't matter. Drives these days have UUIDs and Worldwide Names. By rights, there should be enough information to stamp a "write order" into the metadata so that even if a drive gets moved to another physical port, writing and recovery should be unaffected.

I fell victim to this with md RAID; I had moved some drives around and for some reason mdadm marked every drive as being a spare. During the restoration attempt I screwed up and ended up blowing away the array. Highly annoying.
Click to expand...

Order is really only important when you go to recover the array by rebuilding its meta-data. If the array is in a normal state on just about any controller (3ware, LSI, areca) you can shut the machine down, swap all the disks into different orders and the array will still work fine.
 
You must log in or register to reply here.
Back
Top