RAID Controller vs HBA: IT Mode and When to Use Each
The card between your drives and your operating system determines what those drives can do, and choosing the wrong type is one of the more expensive mistakes in storage because it is discovered late — usually when a software storage layer refuses to work properly with hardware it cannot see through.
This guide covers what RAID controllers and HBAs each do, when you want which, and why IT mode matters.
Two different jobs
A RAID controller owns the drives. It builds arrays, calculates parity, manages rebuilds and presents the result to the operating system as one or more logical volumes. The OS never sees the individual drives — it sees the array the controller has assembled.
An HBA — host bus adapter — connects the drives and gets out of the way. Each drive appears to the operating system individually, exactly as it is, and anything above decides what to do with them.
That difference sounds academic and it is not. It determines what software you can run on top.
Why software storage needs direct access
Modern software-defined storage layers — ZFS, Ceph, Storage Spaces, various hyperconverged platforms — do their own redundancy, their own checksumming and their own error handling.
To do that properly they need to see the physical drives: their identities, their SMART data, their raw error reporting. A RAID controller sitting in between hides all of it. The software sees a logical volume and cannot tell which physical drive reported an error, cannot read per-drive health, and cannot manage placement.
Worse, both layers end up trying to handle the same failures with different assumptions. The controller may retry or reconstruct where the software layer expected to be told about an error, so the software’s own protection cannot act.
The rule that follows: if the software does the redundancy, give it an HBA, not a RAID controller.
IT mode and IR mode
Many controllers can operate as either, and the firmware determines which.
IR mode — integrated RAID — presents arrays. The card manages redundancy and shows the OS logical volumes.
IT mode — initiator target — passes drives through individually. The card acts as a plain HBA, and everything above sees the physical drives with full identity and SMART reporting.
Flashing a card from IR to IT firmware is a common practice for exactly this reason: someone bought a server with a RAID controller and wants to run ZFS or Ceph on it. It works, and two cautions apply.
Flashing firmware is not risk-free — a failure mid-process can leave the card unusable. And on OEM servers the card may be a vendor-specific variant where generic firmware is not appropriate.
Where you have the choice at purchase, buying a card designed as an HBA is simpler than converting one.
When a hardware RAID controller is the right answer
Hardware RAID is not obsolete, despite how the software-defined conversation sometimes sounds.
Boot volumes. A mirrored pair for the operating system is cleanly handled by the controller, before any OS is running. Software redundancy cannot protect a volume the OS has not booted from yet.
Traditional workloads on traditional filesystems. A Windows file server or a database on a conventional filesystem has no software layer wanting direct access. Hardware RAID does the job with less to configure.
Write-back cache with battery or flash backup. A controller with protected cache can acknowledge writes before they reach the platters, which improves write latency substantially on parity arrays. The backup ensures cached writes survive a power loss.
Offloading parity. Parity calculation on the controller rather than the host frees CPU, which mattered more historically but is still relevant on constrained systems.
Predictive failure and vendor tooling. Enterprise controllers integrate with platform management, reporting drive health into the same interface as everything else.
The firmware validation consequence
This connects directly to something that affects every drive purchase for an OEM server.
Enterprise RAID controllers — HPE Smart Array, Dell PERC, IBM ServeRAID — validate drive firmware. A drive without vendor coding may be flagged as unsupported, may not report health telemetry correctly, or may be refused during an array rebuild.
An HBA in IT mode generally does not care. It passes the drive through and lets the software above decide, which is one reason non-OEM drives are more workable in software-defined setups than in traditional hardware RAID arrays.
That is not a reason to run an HBA. It is a reason to understand that drive sourcing rules depend on what card is in the machine. Our compatibility guide covers which platforms validate firmware and which part numbers apply.
Cache and battery backup
Worth understanding because it decides whether a RAID controller performs well or badly.
A controller with cache can hold writes in memory and acknowledge them immediately, then commit to the drives afterwards. That is write-back caching and it improves write latency considerably, particularly on RAID 5 and RAID 6 where every write involves parity calculation.
The risk is obvious: acknowledged writes sitting in volatile memory are lost if power fails, and the array can be left inconsistent.
Controllers therefore pair cache with battery or flash-backed protection. When that protection fails or the battery ages out, the controller falls back to write-through caching — writes are not acknowledged until committed — and write performance drops sharply.
This is a common and confusing symptom: an array that was fast becomes slow with no configuration change. The usual cause is a failed cache battery, and it is worth checking before investigating anything else.
Practical selection
Work through it in this order.
Will software handle redundancy? ZFS, Ceph, Storage Spaces or a hyperconverged platform means HBA, in IT mode.
Is this a boot volume? Hardware RAID 1, regardless of what the data volumes use. Many servers combine both: a controller for boot, an HBA for data.
Traditional filesystem, no software storage layer? Hardware RAID controller with protected cache.
Does the platform validate drive firmware? If yes, source drives by OEM part number regardless of card type.
Then check the physical constraints: connector type and count, whether the backplane uses an expander, and whether the card supports the drive count you plan.
A note on mixing
A server can have both, and frequently should. A RAID controller managing a mirrored boot pair, and an HBA passing the data drives through to a software storage layer, is a common and sensible arrangement.
What does not work is expecting one card to do both jobs on the same drives, or running a software storage layer on top of hardware-assembled arrays and expecting its protection to function as designed.
Sourcing
We supply drives across every major OEM platform and can advise on what your controller will accept. Send us the server model and the controller fitted, and we will confirm whether OEM-coded drives are required before you order.
Our RAID levels guide covers array design, and the drive detection guide covers controller states such as foreign configuration and unconfigured good.
Common questions
What is the difference between a RAID controller and an HBA?
A RAID controller owns the drives, builds arrays and presents logical volumes to the operating system. An HBA connects the drives and passes them through individually, so the OS and anything above it see each physical drive as it is.
Why does ZFS or Ceph need an HBA?
Because they do their own redundancy and checksumming, which requires seeing physical drives, their identities and their SMART data. A RAID controller hides all of it, and both layers end up handling the same failures with different assumptions, so the software’s protection cannot act properly.
What is IT mode?
Initiator target mode: firmware that makes a controller pass drives through individually rather than assembling arrays, so it behaves as a plain HBA. IR mode is the alternative, where the card presents RAID volumes. Flashing between them is common but carries some risk, and OEM cards may need vendor-specific firmware.
Is hardware RAID obsolete?
No. It remains the right answer for boot volumes, for traditional filesystems with no software storage layer, and where write-back cache with battery or flash backup improves parity write latency. Many servers sensibly use both: a controller for boot, an HBA for data.
My array suddenly became slow with no changes. What happened?
Most likely a failed cache battery. When cache protection fails or ages out, the controller falls back from write-back to write-through caching, so writes are not acknowledged until committed and write performance drops sharply. Check this before investigating anything else.
Does the card affect which drives I can buy?
Yes. Enterprise RAID controllers validate drive firmware and may flag or refuse non-OEM drives. An HBA in IT mode generally passes drives through without that check, which is why non-OEM drives are more workable in software-defined setups.
Send us your server model and the controller fitted and we will confirm which drives it will accept.
