Drobo

Drobo v2 didn't like having its drives upgraded

My Drobo v2 is connected via FW800 to a Mac Mini running OS 10.6.1. I’ve had it for a long time… probably over 1 year. Since the beginning, it’s been populated with four 750GB WD hard drives. I have Drobo Dashboard 1.5.1 and firmware 1.3.5

It came time to upgrade a couple drives, so I bought two 1.5TB Samsungs to replace two of the WDs. Monday night, I popped-out a WD and slid-in a Samsung. The relayout took a little less than 3 days, but the Drobo returned to a working condition. So, I replaced another drive.

This time, the relayout took about 2 days and finished sometime last night. When I woke up this morning, all drive lights were green and the blue indicators showed I had increased capacity. However, Drobo Dashboard claimed that there was no Drobo connected. Drobo was viewable in Finder, but browsing non-cached directories caused Finder to crash and I had to do a hard shutdown.

While the computer was off, I unplugged the Drobo even though it never went into standby. When I plugged it back in, it went through the routine bootup and then displayed no lit drive indicators, a blinking power light, and lit blue lights corresponding to my used capacity. I let it sit like this for 20 minutes. During that time, I could hear very infrequent hard drive access. Eventually, I unplugged and followed these directions to “reset” the Drobo.

At this point, the Drobo will boot and go into a relayout for about 30 seconds. Then, the drive lights and power light goes red and the Drobo reboots. It has repeated this sequence about 10 times before I decided to pull the power.

I am now faced with the possibility that my data is gone and the Drobo has acted completely contrary to the marketing material. Hopefully there is something I can do to recover the array.

As long as you ejected all the drives like the instructions your refer to said, then your data will still be on the drive pack.

Sound like your Drobo chassis itself might be bad.

I’d contact Drobo support and see what’s up. Describe everything you’ve done, and keep your drive pack safe.

Sounds more like a drive has failed during the relayout process.
I would recommend opening up a support case.

I opened a support case around the same time I posted this yesterday. To my surprise, I got a response back rather quickly on a weekend and had a back and fourth conversation for a bit. However…

I got very anxious trying to recover my data before support got back to me. I shut down the Drobo and ejected the last Samsung drive I installed under the assumption that it was faulty. I then let the Drobo power-up with only the last 3 successfully-built drives connected. To my pleasure, this didn’t cause the Drobo to reboot or do anything funky. It was just acting like a drive had died. So, I threw a Seagate 1.5TB into the empty bay.

As of right now, the Drobo is doing a relayout with the Seagate drive which has many hours left to go. But, I was able to get the partition mountable again by disabling journaling on the partition and then running a repair from Disk Utility. It seems like my data has survived this ordeal.

Now the question is if this Samsung 1.5TB is broken or the Drobo is being picky. I plan to run some diagnostics on it later. Has anyone else had any luck with the Samsung HD154UI?

Dunno if it helps you any, but I’ve got 4x 1.5TB Samsung EcoGreen F2 HD154UI’s in My Drobo v2, working fine so far… I hope :slight_smile:

When I last posted here, I had just put a Seagate 1.5 in place of a Samsung 1.5 and it was doing a relayout. Not surprisingly, toward the end of the relayout, the Seagate did the exact same thing. Constant rebooting.

After speaking with Drobo Support, which has been nice and responsive, I was sent a replacement Drobo which arrived yesterday. While I was waiting for the replacement, I was able to copy all my data off the old Drobo. I started-up the replacement Drobo by putting in the 3 drives that have been working in the old one. Hoping the replacement Drobo would properly complete the relayout, I inserted the Seagate 1.5 once the replacement Drobo was up and running.

I will admit that I was surprised when the replacement Drobo started rebooting randomly in the middle of relayout less than 10 minutes into the process. This time, the replacement Drobo completely hosed my filesystem. I don’t know if the corruption would have eventually been fixable, but I let Mac OS Disk Utility try to repair it for 4 hours before I finally pulled the plug.

There’s no way around it, the Drobo failed me in two key aspects. One is the ability to increase the capacity of an existing array. The second is protecting my data. I think it’s inexcusable, but there’s not much I can do about it.

Last night I decided to end this pain and reset/reformat the Drobo with the exact same disk pack that it was unable to relayout properly. Naturally, the reset/reformat went on without a hitch and I now have the healthy, larger array I was after.

I don’t know if I’m still a fan of Drobo. The features are great compared to traditional RAID arrays, but those features completely failed to deliver when put to the test. Right now, my data is being copied back to my old Drobo. If I decide to keep the Drobo as my primary storage, you can bet I’ll have a full backup before attempting a disk swap in the future. I really suggest you do the same.

Hello Robricc

could it be that your Seagate drive is the culprit. There were ton’s of issues with this product

Siegfried

I had a very similar problem when upgrading 2 of my previous 1TB drives with 2 WD Caviar Green 2TB WD20EADS (first one, then the other) : the Drobo would not accept the new drive, and at some point, all 4 leds were red and it looked like I had lost all my data.
Contrary to you, I finally recovered all my data, but I had to go through 3 agonizingly slow rebuilds, including 2 which were interrupted by a power outage during a thunderstorm ! It took me more than a week total, during which I was not too sure my precious data would reappear or not.

At the end I was so disgusted with Drobo instabilities that I opened a support case (#00038967) and sent the Drobo log in. DRI sent me a replacement Drobo as if it was a HW problem, but to me it smelled badly of a software problem.
In my case, it was made worse because I wanted to replace specifically one of my 4 1TB drive, which was in position #3 and the noisiest, but once the Drobo had reached the 95% filling threshold, it absolutely wanted to force me to replace drive #4 (same 1TB capacity as drive #3) and totally refused to rebuild drive #3 instead when I extracted this one first.

Just like you this experience made me wonder how much “safe” is a Drobo…
Going through the forum, one can unfortunately see that such cases where people tried to upgrade a drive, failed, and finally lost all their data is not so rare.
It is frightening to think that the data you built during months or years and for which you have no backup (the Drobo IS the backup) could be totally lost at the first failed upgrade/rebuilt.
I believe Drobo should invest more on diagnosis utilities which can be run in safe mode prior and after a drive upgrade/rebuilt to be sure all active drives are OK and that a candidate replacement drive is OK. Obviously, their event log is not complete enough to diagnose precisely and after the fact those spurious problems, and that is a major worry too.

If the flexibility of the Drobo leads to too complicated and unstable software, may be most of us would be better with more classical RAIDs…

Are you aware that Seagate makes more than one model of 1.5TB hard drive? Did you miss the part where the relayout failed with a Samsung drive first?

This is my assumption as well. Now that all drives have been taken out of the Drobo and tested, I can say the hard drives are likely not to blame. Since both my original and replacement Drobo didn’t work with my disk pack, it’s also reasonable to assume that my Drobo hardware is also OK.

This weekend, my original Drobo was upgraded from 1.5, 1.5, 750, 750 to all 1.5s. This time around, the relayout worked as expected during the replacement of both 750s. So, for now, my Drobo seems to be healthy again.

It sounds like a pain. Drobo is not a backup, though. It’s fault-tolerant and upgradable but it doesn’t replace having another drive floating about with your data on it.

I’m hoping my month-old Drobo doesn’t have the same problems yours did but I keep everything backed up on a second drive and rsync periodically from Drobo to a separate USB drive. The Drobo is nice but it’s not the most important thing. The data is the most important thing and the Drobo (like any device) could die at any time.

My plan is to always be one drive ahead of the Drobo. My current Drobo has 3 1TB drives in it plus an old 160GB drive I had laying around. It has ~2GB of space available. I purchased a separate 1.5GB drive and put it in an external USB enclosure that I had. When my Drobo starts filling up (and I’ll probably do this around 70-80%), I’ll get an external USB drive-station (the kind you can just slide the drive into but it’s still out in the open) and buy a 2GB (or larger depending on the GB/cost ratio) drive and put it in it. I’ll then copy from the 1.5GB drive to the 2GB drive (thus eliminating any Drobo goofs) and when that is successful I’ll pop out the 160GB drive, let the rebuild happen, and then pop in the older 1.5GB drive. I figure this is the safest way to go.

Strictly speaking, you are right, but it kills most of the interest of RAID systems : basically, instead of having 100% space overhead for data protection, RAIDs only benefit is to make you pay 25% or less.

I do think Drobo is too vulnerable to failure during too lengthy disks rebuilt/upgrade.
Most often, it is when you rebuilt a disk or insert a new one that all the other disks have the most intense activity, going for 3 days (1TB) or more (2TB).
Thus the probability of detecting a drive failure on the NON replaced/rebuilt drives is then maximum, and unfortunately it is also during this time that the data is NOT protected.
My worry is that the possibility of recovery is not even clear : in case of a replaced drive, is it possible to put back the removed older drive, and have the Drobo do a recovery from there ?
If one makes sure no new data is written to a Drobo during a rebuilt/upgrade, is that enough to ensure the Drovo will always be capable of recovery if it detects a read-only error on the NON replaced disks during rebuilt ?

The fact that Drobo does not support SMART stats does not help : one could have a drive ready to fail before a rebuild, not know it, and the rebuilt would inevitably force the failure.

I do believe DRI has to do something on the software side to drastically decrease the probability of unrecoverable errors during a rebuilt/upgrade. That includes pre-rebuilt tests utilities, check points, different procedures, etc…
I suppose most of us would feel MUCH safer if, like APC for its uninterrupted power supplies, DRI offered to pay 100 000 $ in case of irretrievably lost data on a Drobo !

I think it’s best to look at Drobo or RAID as: it may protect you and it’s better than a single drive.

With a single large drive if the drive dies you’re done. With Drobo/RAID you can still function, replace the bad drive, and generally speaking, things will get back to where they were. You still have the possibility with this setup that things just go completely out of whack and that you effectively lose the logical drive. I’d expect RAID to be less prone to this but it’s still a possibility.

If your data is important then you need a backup - somewhere on something, you need to have something that you can go back to and restore data from. I don’t see anyway around this. Even if you had RAID with mirroring (I forget which RAID level that is) you still have the possibility that something could go wrong on the controller and corrupt everything or there could be some power glitch that knocks it all out. A USB drive sitting to the side with all of your data on it will save you.

I do understand the inclination to think: Drobo/RAID will make it so that I no longer have to backup. It really isn’t true, though.