A photographer’s Drobo showing two amber bays at once. BeyondRAID is proprietary and undocumented, so no standard tool reads it — and that, rather than the two failed disks, is the actual difficulty.
This is a scenario, not a case study. It describes a failure pattern we handle regularly and how it is approached, written from the technical work rather than from one client's job. Our documented case files are here.
A proprietary array — Drobo's BeyondRAID being the best known — stops presenting its volume, or the chassis itself fails. Unlike a standard NAS, the disks cannot simply be read on other hardware, because the layout is not one any standard tool understands.
Proprietary arrays offer genuine advantages: mixed disk sizes, capacity added without rebuilding, redundancy adjusted on the fly. Delivering that requires abandoning fixed stripe geometry in favour of a block allocation map that records where every chunk of data physically sits.
That map is the array. Without it the disks hold data in an arrangement with no discoverable regularity — there is no stripe order to derive because there is no stripe order.
The consequence is dependence on the vendor's implementation. Where a standard mdadm array can be assembled on any Linux machine, these can only be read by the original hardware or by a laboratory that has reverse-engineered the format.
On a standard NAS a dead chassis is an inconvenience: put the disks in any other machine and read them. On a proprietary array it can be the whole problem, and where the manufacturer no longer exists or no longer supplies replacements, a working chassis may be genuinely unobtainable.
Which is why these arrive here more often than their market share suggests. The disks are frequently healthy and the route to them has closed.
Recovery means parsing the allocation map from the disks directly and reassembling the volume from the images according to it — work that depends on knowing the format rather than on any general technique.
Yes, though it is more involved than a conventional array. BeyondRAID is proprietary and undocumented, so the mapping structures have to be reconstructed from the disks rather than derived by testing standard stripe patterns.
Because it does not use standard striping. Data is distributed in variable-sized chunks with redundancy applied per-region and a mapping layer recording where each block sits — which is what allows mixed disk sizes, and what makes conventional geometry testing useless.
Not necessarily. A flagged disk is often not destroyed — frequently it has bad sectors or dropped out under load while still reading. In a virtualised layout every readable sector from a failed member directly reduces the shortfall.
No. That prompts the unit to rewrite its mapping structures, which are exactly what a recovery needs to read. Power it down and leave every disk exactly where it is.
Yes, including any the unit has flagged as failed. Because redundancy is applied per-region rather than uniformly, some areas have no protection at all — and only the original disk holds those.
From £500 plus VAT after a free 48-hour diagnostic, with a 50% deposit where a member needs physical drive-level work. Send every disk, labelled by bay if you know the order.
The chassis dependence adds a failure mode standard arrays do not have. Redundancy inside the unit does nothing about the unit itself.
The allocation map is distributed across members. A partial set is frequently not reconstructable, and bay order still matters for parsing it.