tl;dr version: An external disk wouldn’t mount; I panicked and tried to fix it, then I just gave up and it fixed itself – specifically, the fsck_hfs daemon fixed it for me.
Yesterday, I rebooted my the Mac mini in my office into Windows to play some games, then when I rebooted back into OS X, my Drobo wouldn’t mount.
The status lights on it were all normal, and the Drobo Dashboard (which coincidentally I think failed with ‘missing components’ necessitating reinstalling) reported it was healthy too, but while the drive showed in System Information and in the Disk Utility tree, if I tried to mount it it just reported that it couldn’t, and suggested that I should try to repair it.
I was a little nervous of doing this since a Drobo uses an unusual disk structure, but its own support documents say you should indeed try repairing the disk if it fails to mount. (It’s not actually surprising, since the Drobo’s unusual system should be entirely hidden from the Mac; so far as the Mac is concerned, it should be just like any other disk.)
Disk Utility, however, reported that the disk was unrepairable. Now, I tried connecting it using USB 2.0 (rather than FireWire 800), and connecting it to another Mac, but still, no dice. I was beginning to resign myself to buying Disk Warrior to laboriously reconstruct the directory structures, but I wasn’t quite done troubleshooting yet.
My next step was to connect it to yet another Mac, and now I got a faint glimmer of hope. This was my wife’s MacBook Air, which is still running OS X 10.9; both my Macs had been upgraded to 10.10. Clicking on iStat Menus, I saw that the fsck_hfs process was running, taking up a lot of the CPU. This is a background process that checks and repairs disks, so with nothing to lose — and knowing that a Drobo support document I read earlier said that if fsck is running, let it complete — I just left it and went to watch telly.
I came back a couple of hours later, and boom; the Drobo was mounted on the desktop of my wife’s Mac. Now, one detail I omitted earlier was I had noticed that when the Drobo was connected to either of my Yosemite Macs, a process called diskarbitrationd grabbed a whole chunk of the CPU. Googling it suggested it’s a process just concerned with mounting disks, so I had thought it was getting stuck because it couldn’t mount the Drobo. I can’t find information to suggest diskarbitrationd is a successor to or incorporates the repair elements of fsck, but it’s possible that had I just left the Drobo connected to the Mac mini when I first noticed the problem that it would have repaired itself there too. I’m a little annoyed that the Mac apparently had the ability to repair the disk, but loading Disk Utility and clicking Repair – the obvious troubleshooting process – failed with no hint that an invisible, background process was actually capable of doing it, not least because if you know less than I do, you’d just assume that your data was gone, and either start a lengthy restore process or start spending money on new disks.
(The data on the Drobo – mostly our iTunes Library – was backed up, online, to Livedrive, but the idea of downloading 4TB data, even on a fibre connection, wasn’t one to fill me with delight.)
I’m pretty paranoid about backup and data security, but this episode was a reminder that however you protect your data it’s never absolutely safe; all you’re doing is reducing the risk. The Drobo system allows for a single disk (or, depending on your configuration, two disks) to fail mechanically without losing any data – just pop out the duff disk and slot in a new one, something I’ve done in the past – but as I was reminded even this doesn’t ensure the data is secure, since it only protects against one particular (albeit major) source of data loss.
It’s important to point out that I believe the Drobo system itself was entirely blameless in all of this; I think the fault was one that could have affected a simple single-disk USB drive, and would have been fixed in the same way.