Drobo

Drobo Dashboard - DroboPro - All drive lights red - Too Many Hard Drives were Removed

Summary - All disks for a drobopro are installed, eight 2TB disks. DroboPro has eight red lights on and drobo dashboard has the message too many hard drives were removed. Even though drobo dashboard indicates that too many hard drives have been removed, entering into the advanced settings of the application shows that all disks are installed and they are all 2TB disks. that is to say NO DRIVES HAVE BEEN REMOVED, just the Drobo Dashboard application says they have been removed.

I had long ago selected the DroboPro set up the disk pack using dual disk redundancy, this option was enabled that is it was not turned off.

DroboPro with the follow disk pack:

1 - WD Green 2TB
2 - WD Green 2TB
3 - WD Green 2TB
4 - WD Green 2TB
5 - WD Green 2TB
6 - Seagate Barracuda 1.5TB
7 - Seagate Barracuda LP 2TB
8 - Seagate Barracuda LP 2TB

was upgraded so as to have all 2 TB disks within. The device was healthy and data could be read and written from the unit. When it was time (no need to access the Drobo) the 1.5TB disk was removed and an new 2TB Seagate LP disk was installed.

Drobo DashBoard indicated that the relayout process was “working” and the DroboPro’s lights flashed green and yellow as normal. The process was under way and when I decided to check on the status of the unit, this is when I notice the problem.

Drobo Dashboard for the DroboPro with the hard disk pack as upgraded (5 WD Green 2TB and 3 Seagate LP 2TB disks) indicates the following red error:

Too many hard drives were removed
Too many hard drives have been removed. Please re-insert the removed hard drives.

When I enter into the “advanced controls…”

DroboPro Status indicates that 8 i.e. ALL 2TB disks are installed.

Data Protection - the message here states that “your data is protected”

Suggested Actions - the message here says “too many hard drives have been removed. please re-insert the removed hard drives.”

again, I have not removed a single disk drive and I don’t know if the re-layout process finished correctly when upgrading the 1.5 TB disk to the new 2.0 TB disk.

All disks seem to be working correctly. I hear no disk head or arm or spindle errors or damage.

DroboPro is currently running the newest firmware and all software is up to date.

Firmware Version - 1.1.5
Drobo Dashboard Version - 1.6.8

No volume work, renaming, file transfer, data optimization, disk utility, updates, software installs, read or writes, I/O access, network traffic, host computer work, application access, or anything interfered with the DroboPro and Drobo Dashboard was running as normal with no interference. This appears to be a error or failure.

When searching support, I find Answer ID 278 which references if Drobo Dashboard has any messages or information, such as “too many drives removed” (to many drives removed), too many drives removed (typed more then once just incase search terms need help), yup so Answer ID 278 specifically mentions when contacting support a customer should mention if Dashboard indicates that too many drives have been removed, just there is no information within support about how this issue should be resolved what to do if support is not available.

This issue via the Google search comes up with nothing.

This issue when searching drobo forums has a reference to an older model Drobo not drobopro that had this issue, however it was moderator referred to support with nothing indicating if the issue was resolved and how it got resolved.

too many hard drives have been removed. please re-insert the removed hard drives.
too many hard drives were removed.
too many hard drives have been removed. please re-insert drives
re-insert removed drives
hard drives removed
all red LED for all DroboPro hard drives
DroboPro no data access
DroboPro all RED
DroboPro all red
DroboPro corruption
DroboPro not working
Seagate Barracuda LP
Western Digital Green
all 2TB disks failed
all disks failed
failure
error
lights
LEDs
issue
removed
remove
damaged

Hello,

While this forum IS monitored by DRI staff, it’s probably best to go ahead and open up a formal support ticket from DRI for something like this as they’d probably tell you to do the same on here, or just call: http://www.drobo.com/support/contact-support.php

Most of the help on this forum is community driven, and given your issue, I’d definitely just contact them directly.

Best of luck…

Definitely agree with scotta3234 - this one is one of those “could be the red wire, could be the blue wire” type things, and choosing the wrong thing may lead to KABOOM. So open a support ticket and get personal assistance. We don’t want to be responsible for KABOOM. :slight_smile:

i would say 3. first as primary, then shadow to a secondary who shadow to a third that is off site.

Carver,

That assumes that all 3 devices used will not have some built in terrible management issue. It’s seems impossible that 8 hard disks could have a problem at the same time, but it has…

Dynamic storage and dynamic backup is a fools way to disaster. You’ll hear me yell across the country if data is lost. We just get to enjoy knowing nothing till support has hours and is ready to address my issue.

It drives me nuts that they could say in a support article to organize information before contacting support, then they specifically mention this issue and don’t include ANY additional information. On top of this, why is it not possible to get some indication of the case load before me? I could drive to OWC and beg to pick-up a new DroboPro before support even opens… terrible![hr]
I agree that if support is not going to be able to review the case for X amount of time, that something should be in place to allow someone to check or at least see plan text information contained within the log.

Some type of log analyzer would be wonderful.

Just my opinion here, but Drobo is a consumer-level product. Drobo Pro and Drobo Elite are a bit more - but I’d still considering them SOHO/small business, not enterprise-class. While I don’t discount your experience at all, I think DRI’s business model simply doesn’t cover enterprise-class support. Whether they have enough enterprise-ish-class customers to justify that, I have no clue, but my general suspicion is that they don’t.

My employer sells 10K VTR replacements that have limited (standard) support hours, and 30+K video servers that do qualify for paid (additional charge) 24/7 support, but that’s mainly on a contract basis - so we can pay the folks who are made available whether they’re kept busy or not.

I think in a solution using Drobo that meets your immediacy-of-access needs, caver’s suggestion holds well - lacking the option of “pay someone lots of money to get 24/7 immediate support” I’d go with “pay a reseller lots of money and get extreme (unit) redundancy to satisfy the uptime needs.”

I find it interesting how people often jump to the conclusion of “Oh, they know exactly the answer, but they’re hiding it from me.” I know I’ve done it once or twice… but having worked on the other side, I realized it’s usually "Well, the problem you’re having could be one of 25 different issues. The problem is, troubleshooting can be a destructive process, so pick-and-choose the likely answer could be dangerous and make it worse. Kind of the “it’s on fire!” response of “throw water on it” might be great for a non-electrical and non-oil fire, but if it is electrical or oil, it’ll make it worse.

But back to your initial point… I would love for there to be a 24/7 electronics store… things always break when the store is closed! Damn Murphy and his laws!

Love the 5 stages of data hell

Need to point out what selling point is used on the DroboPro’s overview:

DroboPro delivers both enterprise-level data safety and unprecedented expandability, featuring single and dual disk redundancy combined with instant capacity expansion. Once you experience DroboPro, you just might forget the differences between all eleven traditional RAID levels. If you do, don’t panic. You’re experiencing the peace of mind that comes with every Drobo® product.

Should we mention you have to have a product’s serial number to join this forum so as to keep private impossible tails of terrible failure? Oh, peace of mind that comes with having no support.

Did we mention that dual disk redundancy means jack when our device randomly fails in a way that we seemly know can happen? No Headache Dual Disk Redundancy… OH THANKS IT FEELS LIKE YOU’VE JUST HAMMERED ALL MY FINGERS

it is unfortunate that support dont work weekends.

in order to figure out what happened, they will have to unscramble your logs and take a look.

Your best bet would be to get on the phone with them first thing monday morning.

Don’t believe Marketing. Trust me, I work in Marketing. :slight_smile:

I sincerely hope Support can shed some light on what’s going on. It’d also be good for DRI to re-evaluate their manufacturing and QC processes, as it sure seems like there are more people having issues as of late. Could just be a result of increased sales, but still…

Issue- DroboPro Drobo DashBoard error to many hard disks removed aka TMHDR

TMHDR = To many hard disks removed

Update -

I was contacted by a standard support rep. (I will not include name as my personal decision), who simply verified the issue. It should be noted that this contact was received Sunday March 28th, i.e. after-hours based on standard listed support working times. For the sake of detail this 1st response came within minutes of 24 hours after I submitted to support.

I responded to this 1st response within 2 hours.

Support personal (again my decision to keep things anonymous) contacted me for the 2nd time this morning March 29th. By morning I mean what could be considered standard for entering your office, reviewing whatever work was underway then being informed of whatever work might be addressed in the future.

This second contact was from a Support Engineer, i.e. a personal communication from what otherwise is the highest tier individual within “Support”. I should mentioned this reply contained contact information that is personal, outside of standard 1-800-“system” information (I will not provide this information to anyone, so as to respect some business etiquette.)

This 2nd contact contained verification that diagnostic logs were being reviewed. Specific information that only could be referenced given the review of said logs and an indication that this problem would be corrected, resulting in downtime being the only consequence.

No cause or specific finding was provided. I have not specifically asked. Really I don’t care…

Above I mentioned “logs” for in my personal review of support information, I discovered ANSWER ID 167 for question “the rebuild process is taking an excessive amount of time and the disks are spinning down while in the middle of the rebuild. is something wrong here?”

Keep in mind, we are talking about a DroboPro with dual disk redundancy enabled. This unit was healthy with full I/O access and no “issues” of any kind. To create a 2TB disk pack, the only 1.5TB disk was removed (it was a Seagate 1.5TB disk, but had already been verified as approved for use with Drobo given ANSWER ID 235 for question “do Drobo stroage devices work with Seagate 1.5TB drives?”).

So the relayout process beings. Had it completed correctly the unit would have contained only 2TB disks 5 of which are WD Green, the remaining 3 Seagate LPs.

Regardless, the relayout process ran for about 24 hours… no indication of failure was given either via DroboDash Board or via review of host computer logs.

Now, going back to my communication with support, I provided some historical information of a factual nature for the operation, usage, and upgrades of contained disks. I specifically addressed that I had used 1.5TB seagate disks, yet all of these disks had already been verified as having good firmware. I should mention that I provided this information without being asked… I just assumed that the only help I could provide would be that of how I use the device.

I mentioned that I did attempt to correct the issue given the information contained with ANSWER ID 167. I also mentioned that the just removed disk was still removed and would not be used otherwise. The 2TB disk pack (all 8) was still not working, no disk utilities had been used AKA to repeat, I had not attempted anything to address this issue other than the step by step of ANSWER ID 167. I did not even attempt to try different connection methods from DroboPro to the host computer.

This communication from support was acknowledge within a few hours.

I provided more information (again without being asked). This was again acknowledged.

To conclude, I started to imagine what the heck was going on regarding the case, so I assumed it was log review, I decided that to maintain helpful and proactive assistance, I sent a contact to mention my willingness to send the unit, if that would help. I also defined that nothing was being done with either the DroboPro or the host computer. By nothing I mean software updates or installations etc. etc.

The final contact for the day from this Support Engineer was that a solution was in development, specifically for my issue. That at least in this case, it was never before seen. I was given an expected time for when solution would be provided. The statement was made that this issue should be resolved with no data damage.

It was not specifically said, so I’m forced to make my own personal conclusions, but I think it’s plain to infer support’s review of the log (at least those working on this issue), allowed for the:

1 - Verification of problem
2 - Validation that the physical unit would not be needed for testing
3 - Indication that data access could be restored
4 - Planning of solution

Again, although I got a “we’re working on it” … i was given “things should be ok” … now wait a second if you think these are direct quotes, they are not, rather easy summaries.

I have no way of knowing what is actually going on… I will update as appropriate.

I was told that DroboPro could be disconnect from the host computer, which I’ve done… the unit remains connected to electricity; however is in standby AKA sleep mode.

Both log files sent were 1 MB in size. They were generated within 10 minutes of one another… 1MB of text is about 500 pages or a thick book… I’d sure hope to be able to get or share more information regarding what is within the 2^20 bytes that seemingly will allow for is unknown problem getting resolved.[hr]
Now to be subjective…

If you review Support Answer ID 278 for question “what information should I have before contacting technical support?” you’ll see a reference:

When you launch Drobo Dashboard, what do you see (normal Drobo/DroboPro information: “Ready for Connection,” “Too many drives removed,” unlabeled, unformatted, etc.)?

this would indicate that TMHRD (too many drives removed) as an error has been programmed to occur, yet the acknowledgment that too many hard disks removed from the DroboPro has not been experienced before would to me indicate that via software, the problem was thought to have been addressed.

I can’t imagine what could have caused this issue. Anyone else experience DroboPro issues when connected to a Mac Mini (current 2.53 mini) running Mac OS X Server from a clean install of 10.6 updated to 10.6.2 via Firewire 800 1394b (keep in mind this problem 1st occurred a few days back, so Apple releasing software update to OS X version 10.6.3 today has no relation to this TMHRD issue).

I can only find a few references to TMHRD as an error, not a single one for the DroboPro

Amen to that… now if I can only teach this to my wife… :wink:

Thanks for the update - sounds like support is getting you somewhere, which is very comforting to hear.

I guess it’s one of those situations of “it’s not if something bad happens, it’s what you do when something happens.”

Still no viable resolution or solution.

hello did you got any answer to your problem. I got the same problem that you have but with a drobo 2nd gen.

I’ve got this issue trying to replace one small drive with a large drive. i’ve been though a few rebuilds. Tried hot swapping and shutting down to no avail. Any solution ideas? Drobo is very temperamental loosing random drives in this process and i’m fed up with long rebuilds to get back to square 1!

you haven’t really given us any information

you would be better off starting a new thread - outlining what you did and what happened

you took out a smaller drive - put in a larger drive - and then you talk about multiple rebuilds?

did it not accept the larger drive?

we need some actual information - you cant just post at the end of a 2 page long thread and says “i have this too”

you dont even say what drobo you have?

sorry, will start a new thread!

(that might have also been directed towards hdubois)

Did you eventually sort this out? I’m having the same problem.

Direct Engineering support from Drobo resulted in custom firmware which facilitated some data recovery. The recovered data was 70% good & 30% corrupt. I had to agree to a NDA for some firmware provided. The good recovered data had other more simple issues such as file structure, extended attributes, ACLs problems. There were challenges with the recovery process specifically hardware stability (random reboot & temperature for example), this was all CLI.

When checking hardware, no issues after the disaster were found, firmware returned the Drobo to normal and all disks S.M.A.R.T status was verified good. I did not use this Drobo again, it sat on a shelf for 2 or 3 years until getting water damaged and recycled.

I was told this issue was likely due to the combination of very different disks, using 5400rpm WD “green” disks was a very bad choice. Based on conversations and reviewing logs, I assume how the Drobo monitors disk behavior played a part. The Drobo Engineer also mentioned a possible connection with iSCSI on MacOS, the disks in the pack, and the type of data. It as never clearly defined what caused the problem.

Unfortunately I was developing a data project back then, so the work and complexity of backing up put me about 2 months behind. It took over a month of trial and error to get the data off the Drobo (this avoided a lot more time being needed to start fresh) and includes time working with the Drobo Engineer. Over another 6-18 months what data still had value was generally recovered. The recovery process was so bad tools needed to be created to fix issues. I never asked Drobo for anything, just wanted the help in getting data. They did at one point offer me a pretty significant discount on hardware, which I declined.

There is a hidden cost in purchasing anything, for the Drobo Pro it was extremely expensive.