Torture Testing
I created a test volume on the DroboPro.  I named it as such because I fully intend for it to fail at some point during my thrashing.  I copied test files with known MD5 hashes to and from the DroboPro.  It did just fine, but considering that is its primary purpose, this is not really news, so I quickly spiced things up a bit.

Testing continued over the next several days.  I performed every conceivable combination of simulated drive failures, rebuilds, migrations, and power loss.  I streamed data from the DroboPro during all operations as to detect inconsistencies and data corruption.  Drive failures were simulated by ejecting a drive mid-operation.  Power failures were simulated by mercilessly yanking the power cord while the unit was in operation – most of these with a streaming write taking place.

After each power loss, the DroboPro came back up, collected itself, and reappeared under Windows with all data intact.  The only exception to this was a file being written *during* the loss might come back incomplete, but this is no different than any other storage medium suffering this type of interruption.

Simply pulling a plug was not enough for me.  I turned up the heat by killing power to the DroboPro during the following operations:
  • Migration from single to dual drive redundancy (and vice versa).
  • Addition of a drive.
  • Failure (removal) of a drive.
  • Creation of a volume.
  • Creation of a virtualized smart volume.
  • Combinations of the above, i.e. failure of a drive during a redundancy conversion.
  • Cascade failure (second drive failed after initial rebuild began), followed by installation of 3 new drives.
  • Sequential cascade failure of 6 out of 8 drives, followed by simultaneous replacement of the 6 removed drives.
During the cascade failure testing, I uncovered some additional factoids.  As I failed drives and the DroboPro did what it could with a storage pool slowly diminishing in capacity, I got to the point where actual free space was just slightly larger than that used by my test volume.  Since the pool was in effect filled to capacity, the software threw up a warning to that effect.  That and other various warnings presented during failure testing appear below:

Data Robotics, Inc. DroboPro 8-Bay In-depth Review - Storage 55Data Robotics, Inc. DroboPro 8-Bay In-depth Review - Storage 56Data Robotics, Inc. DroboPro 8-Bay In-depth Review - Storage 57

Various warning / caution prompts provided by Drobo Dashboard.

It is worth noting that once the DroboPro reaches 95% capacity, along with the various warnings it lights up an additional front panel light to try and coax you into inserting a drive in that location.  In addition, the unit begins to throttle back on write speeds.  The further you push past 95%, the slower it goes.  This is on purpose as without the Dashboard installed, it is the only way it can try adn keep itself from being overfilled.

After each of these much more obscure and crazy combinations of stacked failures, the DroboPro power was restored.  There were some cases where it would take a few minutes to compose itself, but it came back each and every time, doing so without fault and with all data remaining intact.  Once it was back up and running, it immediately and automatically resumed whatever it was doing prior to the power failure.  I even pulled a maneuver that typically roasts a standard RAID:

Data Robotics, Inc. DroboPro 8-Bay In-depth Review - Storage 58

Yup, I pulled 3 drives at once, with the array live and kicking… well, it was kicking.  The red-lettered text above is the DroboPro’s way of singing Daisy.  I followed its instructions before being blown out of an airlock and saw all data safely returned after only a few short minutes taken while the unit composes itself.
« PreviousNext »