Has anyone tried this? Am I about to lose data?

Forum History Drobo
1

In working on the recent “issue” I uncovered while upgrading firmware on my Drobo from 1.3.1 to 1.3.5, after bouncing around between several unhelpful support staff, it was suggested that I swap drives in my Drobo; specifically that I take the top drive and put it in the bottom slot, and put the bottom drive in the top slot, and boot the Drobo back up.

Has anyone tried this?

My gut says doing this is going to trigger a rebuild of the entire array, trashing the data stored upon it.

My Drobo currently has (from the top down)

  1. 1TB
  2. 750GB
  3. 1TB
  4. 750GB

There was 1.2TB of data stored on the Drobo, out of an 8TB slice. drobo-utils reported 82% usage of the array when queried.

Where that data exists, and how it was spread across the drives, is a mystery.

I’ve emailed support asking them what risk I’m putting myself in by doing this, but I’d like to hear back from anyone else who might have also done this (independently or at the suggestion of DRI support).

2

As long as it is the same disc pack the disc order is not important, drobo recognizes disk pack and manages disk order automatically.

3

Hrm, anecdote… since the forum “upgrade” here, I’m no longer receiving email when I check the box to be emailed when there’s a reply here in the forums. Hrmph!

4

@hacker, as long as your Drobo is powered off there is no harm in removing drives and shuffling them between slots. If the Drobo is on and you pull out a drive the Drobo thinks it a drive failure.

5

yeah, i’ve re-arranged my drives several times for various reasons.

drobo itself doesnt have any idea which drive is in which slot, part of its boot process is to query each drive, so as long as they are all there, it makes no difference what slots or orders they are in.

I am guessing perhaps there is information about the disk pack stored on every drive, and it reads this from the first drive , and perhaps that is corrupt, so by swapping the first drive - you will hopefully give it a non-corrupt version fo your disk pack information so it can finish the boot.

that is all i can think of as the rationale between swapping the disks around.

but rest assured it wont trigger a rebuild or make anything any worsee

6

If one drive takes a longer time to start/spin up, Drobo boot might be getting “stuck” on querying that drive. Putting it in a slot that is queried later will allow it sufficient time to be ready, then Drobo doesn’t get “stuck” on it.

I’ve had this happen on other RAIDs, but a drive that’s slow to be ready is often a pointer to a drive going bad.

7

Support had me swap disks around ages ago to help diagnose an issue I was having with hot drives. It made no difference, not even to the initial startup I had three drives in it at the time.

8

good point bhiga (about the spin up times & about the fact this should set alarm bells ringing)

but again, it does seem coincidental that this coincided with a firmware upgrade, i wonder if they changed the tolerances/wait times?

9

Ok, I swapped the drives as suggested, plugged the data cable in, then power.

The Drobo powered up, ran through the chase, got to the 7 right-most, blue LEDS with the green light blinking, and that’s how it has been for about 10 minutes so far, not going further. The Windows laptop with the latest Drobo Dashboard is blinking with “Ready for Connection”, but nothing more.

I’ll leave it plugged into the laptop and see what happens. Maybe this will take days or weeks for it to scan/repair/recover/boot, who knows.

As long as my data is still safe on the physical platters, I don’t care what happens to the “firmware” side of the disk pack.[hr]
No luck.

I’m back to 7 blue LEDs from the right, and the device still isn’t seen by the Windows machine that it is plugged into. :frowning:

Back to DRI support I go…

10

4 days, and not a single change in the Drobo.

I have to wonder… based on the green light blinking after the initial blue LED “chase” and then going solid after a few minutes (while the LEDs haven’t completely filled), if the internal fsck is taking longer than the drive init timeout, so it gets into a deadlock condition.

In other words, if the drive initialization step had a longer timeout, maybe the internal fsck would finish and complete booting.

I’ll just let it sit and wait it out. I have a powerful cyclone fan blowing through the disk pack from the front to cool them down, because without it fully booting, the Drobo internal fan in the back never actuates (a pretty significant problem).

I’m still waiting for DRI Support to come back with the next thing to try.

11

keep coming with the updates, im sure bhiga as well as myself will be very curious to know the explanation (if indeed we ever get one)

12

It appears that I’m completely screwed. There is currently NO DROBO UNIT that DRI will support with more a volume larger than 2TB on it. If you format your Drobo using a Linux filesystem to > 2TB, your data is at risk.

Their website doesn’t specify, clarify or state this with a BIG BOLD WARNING SIGN, but ValorieK from DRI stated that since I’ve create an ext volume larger than 2TB on my Drobo, it is completely unsupported. This includes the DroboPro and other units, which will present themselves to the underlying OS with > 2TB volumes.

The whole point behind me creating an extX filesystem on the Drobo was to handle files with names that NTFS and HFS+ can’t handle. A full OS backup of a standard Linux system can’t be done on either of those filesystems, because their naming conventions do not support filenames commonly used on Linux.

ValorieK indicated that because my Drobo has > 2TB volume, the Drobo can’t boot and recognize it, even though under firmware 1.3.1, this Drobo has rebooted hundreds of times over the last year without incident. The first reboot after upgrading to 1.3.5, started this issue… and I’m supposed to believe this is because my volume is > 2TB?

Ludicrous!

She also stated that the last-resort DRI “read-only” firmware is not an option.

She also stated that downgrading my disk pack from 1.3.5 to 1.3.1 is not possible.

She also stated that shipping my disk pack to a data recovery firm is not possible, because they do not understand the Drobo filesystem layout, and DRI does not publish or share that format.

She also stated that there was nothing else I could do and that I’ve irreversibly lost access to my data, because the Drobo continues to hold it hostage, refusing to complete the boot process. Even though the data is on the platters, presumably intact, it’s gone.

This is absolutely UNACCEPTABLE, and I am escalating it as I write this.

13

so basically they did an undocumented change in 1.3.5 ?

thats the problem with their secrecy - they break things unexpectedly

14

Whatever they did, I can’t undo it, and there’s apparently no way to go back. Herein lies the problem with touching data space on embedded systems; if you don’t verify the upgrade works BEFORE TOUCHING USER DATA, you’re in trouble.

Any seasoned embedded developer knows you never write your firmware to any critical area of the flash/disk/storage, until you absolutely know that the device has completed a boot and test suite successfully.

In this case, until the Drobo booted perfectly with the 1.3.5 firmware, to the point where the dashboard and underlying OS could recognize and address the volume, the disk pack should never have been upgraded.

It may be that they will eventually release a firmware that supports > 2TB volumes, and I can sit and wait until that happens, while my data remains held hostage by a device that refuses to boot, but I need to get to my data, so I can actually USE IT.

ValorieK suggested I use some OS-level tools to try to do some data recovery on the disks, but since the device itself refuses to hand the block-level device over to the underlying OS (any OS: I tried Windows, Linux and Mac), I can’t run those tools.

I’m furious beyond words at this point.

15

Ahhh, so this explains why you’re after replacing the firmware header/whatever in the disk pack…

Not sure about the Linux Dashboard, but I know Windows Dashboard tells you EXT3 has a 2TB limit (when formatting through DroboShare).
http://support.datarobotics.com/app/answers/detail/a_id/23

IMHO I think DRI should be firmer about simply not supporting >2TB EXT3 volumes, versus the “it might work in some environments” - or at least word it in the proper manner of “DOING THIS IS AT YOUR OWN RISK” but that’s just my opinion.

Unfortunately can’t change the past… so… I’m headed back to your other thread…

16

@bhiga Actually we do say that.

http://support.datarobotics.com/app/answers/detail/a_id/120/kw/linux/r_id/100004

Data Robotics has not officially tested EXT3 volumes larger than 2TB. We therefore recommend a maximum volume size of 2TB on an EXT3-formatted volume. If you create a volume that is larger than 2TB on your Drobo storage device, you risk data corruption.

17

:slight_smile: Can I request explicitly cross-linking the two articles (beyond just the “Other users found…” at the bottom)?

18

I can see, what other article did you want cross-linked?

19

If the problem truly is that > 2TB volumes /break/ the Drobo’s ability address them, then don’t simply state you “risk” data corruption, you should state the more-accurate: “Your Drobo may fail to boot, corrupt your data, and you will lose the ability to mount the volume to retrieve your data.” message.

20

IMO the
Which file systems do Drobo and DroboPro support?
and
What volume sizes may I use and what happens if my disk space exceeds my volume size?
articles should also carry the warning from The Drobo and DroboPro datasheets state that Linux support is currently in Beta. What does that mean? (the article you mentioned), or be linked to that article for reference.

The remainder of the KB articles that I’ve seen that mention file systems and limits point back to those two articles, so they’d be covered.