Scott Penrose

Drobo

Scott Penrose is a perl hacker with an interest in home automation. He has been playing with electronics since he was old enough to burn his fingers with a soldering iron.

2011 - why the company, not the device SUX

http://support.drobo.com/app/answers/detail/a_id/575/~/why-is-droboshare-not-displayed-in-drobo-dashboard-version-2.0.0-or-later%3F

Drobo Dashboard automatically updated 2 days ago (September 2011) and I can no longer see my Drobo Shares. After rebooting everything a few times, checking I have the latest, making sure it works on my old computer, I finally turned to the version.

The article above basically says: "DroboShare is not displayed in Drobo Dashboard 2.0.0 or later versions because DroboShare is no longer supported in the latest version of Drobo Dashboard."

Why? To add support for their, old (and I use the word old lightly here, as they are hardly old being a new product 3 years ago) devices would be trivial. I have built software for 20 years, and adding the ability to deal with different drivers, protocols, and systems with more limited capacity is easy.

The above decision shows total disrespect for Drobo Customers and long term supporters - who are the companies bread and butter. Get with the program Drobo !

2010 and earlier

Short version...

See also: Fuppes

  • I have 3 Drobo at home
    • Main storage system on Mac Pro
      • Aperture
      • iMovie 09 (yes I love it, was using Final Cut Pro, but now prefer most little edits on iMovie)
      • VMWare images
    • Videos and Music collection (ripped copies of DVDs and VHS)
    • Shared disk (for all our computers, documents etc)
  • Likes
    • Automatic
    • Reliable
    • Quiet (enough)
  • Dislikes
    • Sometimes performance - not clear when - directory lists are slow !
    • Price - I think their price point is about 30% too high.
  • I am selling Drobos

Reliability

I am sick of reading blog posts from people who just don't know what Drobo is and does.

We regularly see posts where people have lost all their data off a drobo. Their problem, IMHO, is that this is a regular software error. I have had the same issues described by people for the Drobo on other external disks. If you search the net for the same symptoms (e.g. can't mount but no SMART error, or Disk repair wont' work, or folders are empty) you find heaps of references that are nothing to do with Drobo.

The issue we have, is that file systems, whether HFS+, NTFS or Ext4 all still have failures and corruptions.

Drobo, does not protect against these corruptions.

Drobo does two things, and it does them well: it protects against a hard disk failure; and it allows for almost zero management upgrades of disks (also included here is the ability to have mixed size disks).

So backup Drobo - yes - absolutely. How many people have lost data due to hard disk failure? How many due to software corruption? How many to human error (accidental delete or format ...). I know from my own history, that hard disk failure probably only accounts for less than 1/3rd of my data loss. Drobo is an excellent tool to protect against that - now we need the rest.

Can it be done? Using a NAS yes maybe, using Drobo as a USB / Firewire block storage device - this may be harder, but it may be possible... but we are now assuming that Drobo can write better file system monitors than Apple can. Via a NAS this is much easier, because you are dealing with files and data streams, rather than blocks.

Aperture and Performance

There is lots of information about performance issues around the net on Drobo. The most of which I read are about Aperture. Some people are getting good performance the next bad.

I think that I have concluded that the problem is size of directory listings. When copying large files or general file access, I find the drobo faster than my internal drive. But when you load Aperture it has to read in very large number of files. Aperture (very sensibly) uses directory structures rather than a database to store data - this is the way all good software should be written, and a philosophy I adopt in all my development. But in Drobo it seems to be very slow, especially first time through the list (I suspect faster later due to Operating System file cache).

Conclusion: I am still using Drobo as the main disk for a 500+GB Aperture library. If I have time, I will start experimenting with a local disk and compare the performance. If it is faster locally, I may switch to using that and use Drobo for the backup instead. It would have to be lots faster though, i.e. not just startup time or 10%.

UPDATE I have moved to a Raid 0 disk on my mac (two 1TB drives) - giving me the lowest level of reliability, but the highest performance. But... I use Time machine and regular RSYNC backups of my data onto the Drobo. Drobo also contains lots of more rarely accessed media, old projects, VMWare images and more. The other two drobos connected to the DroboShare are still used by 3 machines around the 2 houses here for Movies, Music, Share disk etc.

What is missing

Drobo is foolproof to use. When ever I read a thread on the internet about a problem, it is almost always down to a software problem. Drobo does not (yet) deal with software problems. If I delete a file, write a corrupt file to the disk, kick out the USB/Firewire/SATA cable during a write, have the OS itself write corrupt data to the disk, cat /dev/null > /dev/sdb, or any other possible software/human error - your data is lost !

After using Drobo for more than a year now, after moving away from using Solaris and ZFS, I have really enjoyed the complete lack of any maintenance. It has been great. But to be honest, ZFS had one thing over Drobo - snapshots !

I want to take a snapshot of my music, or my movies, or even more precious data - then any accidental delete or move is protected.

From my mac via the DroboShare, moving a file to trash removes it immediately - no way to recover ! A trashcan that worked across operating systems (this is I think an issue for Samba) is important - but again, if we had snapshots we would not need this.