Hi I’ve had this Drobo Pro for about a month and it has (8) 2 TB drives. I have it connected directly to my MBP 17" via FW 800. I always keep the MBP running when I go to sleep.
Yesterday I came into my office and noticed that my MBP had froze up so I had to reboot it. When it booted back up I saw that the Drobo Pro did not mount. Drobo Dashboard recognized it as well as disk utility. I tried to mess with it for a few hours with no luck. All I got when I tried to verify/repair the disk I got the Invalid B-tree node size error. So I got on tech support with Data Robotics and they told me to run Disk Warrior.
I ran DW and it took almost a whole day to finish and then I was able to mount the drobo. But now I noticed that 90% of my data is lost or missing and it scrambled my files.
I am very skeptical about reformatting and starting over with this because 1.) I have spent weeks loading about 10 TB to this thing and 2.) how can I trust this again? I don’t understand why I got the Invalid B-tree node size error because I have never unplugged this unit from my laptop and have never unmounted it improperly. The only incident was that my computer froze.
Also I don’t see why its worth having if this unit is so sensitive that this can happen from a “improper” unmount or computer freeze.
Can anyone shed some light on this? I am about to return this unit and find another means for data back up.
By chance, are you running Snow Leopard 10.6.1? This sounds similar to an episode I had a couple of weeks ago, which definitely was not the Drobo’s fault. In my case, I had a few-weeks-old clean 10.6.1 Snow Leopard install and had not yet installed Drobo Dashboard. The only other non-Apple software I had installed at the time was VMWare Fusion, so I expect one of the two as the culprit [most likely, the OS].
I have since learned that Disk Warrior likes repairing a drive that hasn’t been repaired by Disk Utility. Like you, I tried Disk Utility first, and Disk Warrior could only “repair” my drive to an empty disk.
I actually was researching the ReadyNAS Pro. It seems like it’s something to consider. I see that it has a capacity up to 12TB at around $4k. One thing I wasn’t too clear on is the interface. It says its gigabit ethernet but in the pictures it also seems to have USB and SATA – is this just to connect external drives or can you connect the NAS to your computer via those ports? Also is this unit compatible with the same drives as the Drobo or do they require a specific type? These are things that didn’t seem too clear in the specs but I have only spent an hour or so browsing Network Storage devices.
A NAS is a NETWORK ATTACHED STORAGE, so no direct connection via usb or fw. The ports are for connecting external drives to automatically schedule backups or to import data from them.
But if you connect the Drobo via Ethernet/iscsi it is like a NAS almost. You can use the same drives (check their comptobility list) I put my Drobo drives in the NAS.
So, @truths…, please make sure I understand what happed. You say that your MBP “froze” and you rebooted it. Then you blame your Drobo because you cut disconnected the brain that controlled the file system? Did you contact DRI support? Did you contact Apple support to understand why your MBP froze?
All we know is that your Mac had a problem. Nothing indicates it was a Drobo problem. AND by your own actions you killed the data on your Drobo. You provide no information about your system. But you did report actions consistent with a self inflicted fatal wound. What, exactly, did you do when you write “I tried to mess with it for a few hours with no luck.” Why didn’t you contact DRI or Apple for help instead of messing around for a few hours?
@Switcher’s back, and here we go again: “It’s not Drobo’s fault you lost your data, it’s your own fault! And even if it wasn’t all your fault in the first place, it is now your fault because you (maybe) did the wrong thing after you lost your data!”
That reasoning just does not make any sense to me. And did you read the original post at all?
@truthsandrights says “So I got on tech support with Data Robotics and they told me to run Disk Warrior.” Then he describes what happened after running DW. Sounds to me like he did contact support and follow their advice, no?
Also, isn’t Drobo in total control of its file system, and shouldn’t Drobo make sure that the file system stays coherent, regardless of what happens on the host? What’s the point of reliable backup/archiving if it’s not reliable in all situations?
Then again, maybe I’ve misunderstood something, because I too am one of guys who bought an expensive but easy-to-use and extremely reliable system and has had nothing but problems since then: bought in early Aug, corrupting data and troubleshooting with Drobo support from Aug to Oct, returned device to retailer in Nov, still waiting for response a month later.
I have never had this many problems with my data, even with drive failures on normal non-redundant file systems. And all this is with healthy drives in the Pro…
Not taking sides here, just adding an observation.
I have lost data by (force) rebooting systems that I thought were hung. This fact has nothing to do with Drobo, as I’ve lost data on controller-attached drives and USB-attached drives through this.
So data loss due to host reboot can happen.
Whether the Drobo was related to the lockup, and whether there’s something wrong with truth’s Drobo itself, I don’t know.
But force-rebooting the host is akin to pulling the USB cable. If there was something happening at the moment you disconnect, stuff can get damaged.
I shudder when people write files to USB devices (esp sticks) then just pull them out of the port without telling the OS. I’ve lost data that way too.
So far I’ve been lucky - my machine hangs haven’t hurt my attached Drobo, and that particular machine seems to be a lemon so it’s got RMAed. Now my Drobo is sitting next to my Vista x64 desktop until it gets its intended host back and stable.
Right, that’s true, but that’s because the host is responsible for the file system on a USB drive - the USB drive has no intelligence, it’s just a block device.
[color=#A9A9A9]With the Drobo, the drive is responsible for the file system, not the host.[/color] Drobo can’t help it if you power down abruptly and lose data, but the file system should always remain intact, in my opinion anyway.
What I’m saying here is that computers do hang up for various reasons, and if that causes your Drobo to lose data, that’s not good. And if it is the Drobo or Drobo software that causes the hangup, that’s even worse. Hope we find out what happened.
Update: the host is also responsible for the Drobo file system, as pointed out in following posts.
As I understand it, the operating system is responsible for the NTFS / HFS+ / EXT3 filesystem. The Drobo needs to understand it for its thin provisioning to free up space properly, but the drobo is not responsible for keeping the filesystem consistent.
Someone from DRI (not Jennifer, somebody else) replied on one of the other threads that the Drobo/DroboPro is just a block device. It “peeks at” the volume bitmap to know how much space is actually in use (for thin provisioning, as ajspencer said), but it doesn’t itself maintain the filesystem.
If the Drobo did maintain the filesystem like DroboShare does, I think we wouldn’t have a 2TB limit in XP.
Ok, you guys do have a point, it’s not as straight-forward as I had thought. But I would agrue the responsibility is somehow shared. Drobo creates the file system (according to DRI recommendations), so I’m holding it at least partially responsible, and Drobo makes the file system redundant, so it’s not only a block device like a USB drive. You can’t freely choose your file system on a Drobo, for example.
I would like to see Drobo take a larger role in maintaining file system integrity, otherwise the expectation of reliability just won’t come true in everyday scenarios, and 16TB is a lot of data to lose.
its “creates” it, i.e. formatting, its hardly rocket science, and its not responsible for what windows / osx does to it afterwards.
just because drobo creates a file system doesn’t mean that the OS cant destroy it.
drobo makes it redundant at the block level - that has nothing to do with the file system… you can rest assured that a corrupted file system is still redundantly protected at the block level - all of your corrupted data is protected against drive failure - they are two separate things.
the only reason you cant choose a file system freely is to do with the thin provisioning/drobo being able to understand the system so it knows how much space is used/it needs