When a storage server fills up, the instinct is to buy another server. Often that is the wrong, expensive answer. A JBOD, a just-a-bunch-of-disks expansion shelf, is an enclosure full of drive bays with no server brain of its own that connects to an existing host and presents its drives as if they were inside that host. It lets you add a lot of capacity without paying for another set of CPUs, memory and licences. Knowing when a JBOD is the right tool, and how the SAS chaining behind it actually works, saves real money. This is the foundational guide to drive-expansion shelves for UK storage builds.
What a JBOD actually is
A JBOD is an enclosure of drive bays, power supplies and the connectivity to attach to a host, but deliberately no compute. It has no operating system and makes no RAID decisions of its own; it simply presents its drives to a host server, which owns them exactly as if they were in its own chassis. The intelligence, whether hardware RAID, software RAID or a software-defined storage layer, lives on the host, and the JBOD just supplies bays and the path to them.
That is the whole point: a JBOD adds capacity without adding a server. You are not buying another set of processors, memory, an operating system or per-server software licences, only drives and the enclosure to hold them, which is dramatically cheaper per terabyte than a fresh server when all you need is more space. The host you already have does the work; the JBOD just gives it more room.
How SAS chaining and expanders work
JBODs connect over SAS, and the mechanism that makes a shelf of many drives reachable through a few cables is the SAS expander. An expander is a switch for SAS: it fans a small number of host connections out to many drive bays, so a host bus adapter with a handful of ports can address dozens of drives in a shelf. The host sees every drive individually through that expander, which is why the host's storage layer can manage them as native devices.
You can also daisy-chain shelves: the host connects to the first JBOD, and that shelf connects onward to the next, extending the SAS domain across multiple enclosures from a single adapter. There are sensible limits to how far you chain before bandwidth and manageability suffer, but within them it is an efficient way to grow. The host bus adapter is the linchpin of this whole path, which is why we size it carefully from our host bus adapters range.
- •A JBOD adds drive bays with no compute; the host owns and manages the drives
- •A SAS expander fans a few host ports out to many bays so an HBA can address a whole shelf
- •Shelves can be daisy-chained to extend the SAS domain across enclosures from one adapter
- •Buying drives and an enclosure is far cheaper per TB than a fresh server when you only need capacity
The HBA and the storage layer own the drives
Because a JBOD has no brain, the host bus adapter and the storage layer on the host are what turn a bunch of disks into usable, protected storage. Present the drives through an HBA in pass-through so the host sees each one natively, then let the host's storage layer, ZFS, a software-defined storage platform, or a hardware RAID controller, apply redundancy and present volumes or pools. The JBOD is just bays; the resilience and the presentation are the host's job.
This is the same pass-through principle that underpins software-defined storage generally: the software wants to own each disk, not have a controller hide them behind a single volume. Match the HBA's capability and port count to the number of drives you are attaching, and make sure the host has the CPU, memory and storage-layer headroom to manage the extra drives, because adding bays to a host that is already at its limits moves the bottleneck rather than solving it.
When a JBOD is the right tool, and when it is not
Reach for a JBOD when the constraint is purely capacity and the host still has compute, memory and controller headroom to spare. If the server has plenty of CPU and memory but has run out of drive bays, a JBOD is by far the cheapest way to grow, because you add only drives and an enclosure. It is ideal for capacity-led storage, backup repositories and bulk pools that need more space, not more processing.
Reach for another server instead when the host is compute-bound or controller-bound, when you need more throughput rather than more terabytes, or when a scale-out architecture wants whole nodes that each bring their own controller power. The decision is the classic expand-versus-add-a-node question, and it turns on whether your bottleneck is capacity or compute. We work through that decision, and size the HBA and shelves for the expand path, in our server configuration service, building dense capacity on the HPE Apollo range.
Putting expansion together
For most UK storage-growth situations where the host has headroom, this lands on one or more SAS JBOD shelves attached to the existing server through a capable host bus adapter in pass-through, with the host's storage layer owning and protecting the new drives, and shelves daisy-chained within sensible limits as capacity grows. The number of shelves follows the capacity needed; the HBA and host headroom set how far you can sensibly expand before a node is the better answer.
We size the expansion path, the HBA, the shelves and the host headroom, and weigh it honestly against adding a server, in our server configuration service. Used well, a JBOD is the cheapest capacity you can add: more room for the server you already own, without paying again for compute you do not need.