JBOD stands for Just a Bunch Of Disks, and it describes the simplest way to combine storage drives: no RAID controller logic, no parity calculation, no striping for performance. Depending on configuration, JBOD either presents each drive to the operating system as a separate volume, or spans them together into one large combined volume using simple concatenation rather than RAID.
What changed in 2026
- More NAS operating systems made JBOD an explicit, clearly labeled option alongside RAID levels in setup wizards, rather than burying it as an advanced setting, as archival use cases grew more common.
- Mixed-capacity drive pools became more practical as storage pooling software improved at handling drives of different sizes within a single spanned volume without wasting capacity the way RAID often does.
- Cold storage and archive use cases pushed JBOD adoption up, since spanned JBOD maximizes usable capacity per dollar for data that is already backed up elsewhere and accessed infrequently.
How JBOD actually works
In its simplest form, JBOD is just multiple drives visible to the system as separate, independent volumes — drive one shows up as one drive, drive two as another, with nothing combining them at all. In its "spanned" or "concatenated" form, software combines several physical drives into a single logical volume, filling the first drive before spilling over onto the next. Either way, there is no parity, no mirroring, and no striping across drives for speed. What you see is what you get: total capacity equals the sum of every drive installed, minus nothing for redundancy overhead.
JBOD vs RAID comparison
| Aspect |
JBOD (spanned) |
RAID 1 |
RAID 5 |
| Usable capacity |
100% of total |
50% of total |
Total minus 1 drive |
| Redundancy |
None |
Full mirror |
Single-drive parity |
| Performance |
No striping benefit |
No striping benefit |
Some striping benefit |
| Drive matching required |
No — mixed sizes work fine |
Ideally matched |
Ideally matched |
| Failure impact |
Data loss on failed drive, possible spanned-volume damage |
Fully recoverable from mirror |
Rebuildable from parity |
When JBOD is the right call
JBOD makes sense when you have mismatched drives you want to combine into usable capacity without buying a matched set, when the data is already backed up elsewhere and you just need bulk local storage, or when you specifically want the ability to pull individual drives and read them independently (which spanned JBOD complicates, but per-drive JBOD supports directly). It is a poor fit for anything you cannot afford to lose, since a single drive failure in a spanned volume can damage or orphan data that spilled across the failure point. If redundancy matters more than maximum capacity, RAID 1 or RAID 5 is the better starting point — see our comparison of RAID 1 vs RAID 5 for how those tradeoffs work, and our best NAS for home guide for choosing hardware that supports whichever configuration you land on.
FAQ
Is JBOD the same as RAID 0?
No, though they are often confused. RAID 0 stripes data across drives for a real performance gain but also has no redundancy — losing any one drive typically destroys the entire array. Spanned JBOD does not stripe for performance and generally only risks the data on the affected portion.
Can I mix drive brands and sizes in a JBOD setup?
Yes, that flexibility is one of JBOD's main advantages over RAID, which generally performs best with matched drives.
Does JBOD protect against drive failure at all?
No, not in its standard form. Any redundancy has to come from backups stored elsewhere, not from the JBOD configuration itself.
Why would someone choose JBOD over RAID 5 for a NAS?
Maximum usable capacity, simplicity, and the ability to use mismatched drives are the main draws — at the direct cost of losing RAID's rebuild protection.
Where to go next