What an HBA actually is

HBA stands for host bus adapter. In practice, when homelabbers say “HBA,” they mean a PCIe expansion card, almost always built around a Broadcom (formerly LSI) chipset, that adds a bunch of SAS/SATA ports to a system. The most common ones you’ll see recommended are the LSI 9211-8i and its many rebadges (Dell H200/H310, IBM M1015, Intel RS2WC080, and others), all built on the same SAS2008 controller, plus the newer SAS3-based 9300-8i for higher throughput. An 8i card gives you 8 drive connections through two SFF-8087 (or SFF-8643 on some) ports, each of which typically breaks out to four SATA drives via a forward breakout cable.

The reason these specific cards show up constantly in homelab guides isn’t hype. It’s that millions of them were deployed in enterprise servers and SANs over the last decade and a half, and when that gear gets decommissioned, the HBAs flood the used market at $15-40 a card. They’re cheap, well-documented, and the flashing process has been done by enough people that almost any problem you hit already has a forum thread answering it.

Why “IT mode” is the part that actually matters

This is the detail that trips people up. The same physical card usually ships (or can be flashed) in one of two firmware modes:

IR mode (Integrated RAID). The card presents itself to the OS as a hardware RAID controller. It can build RAID 0/1/10 arrays in firmware and hands the OS one or more virtual disks instead of the real drives. This is what these cards were built for in their original server role.

IT mode (Initiator Target). The card acts as a dumb pass-through. Every physical drive attached shows up to the OS individually, with its full SMART data intact, and the card does no RAID logic of its own at all.

For anything running ZFS (TrueNAS, Proxmox with ZFS, Unraid’s array, or a plain Linux mdadm/ZFS build), IT mode is what you want, full stop. ZFS is designed to manage redundancy itself, at the filesystem layer, with direct visibility into each disk. Put a hardware RAID controller between ZFS and the drives and you lose exactly the things ZFS needs: real SMART data for zpool status and scrub reporting, direct control over which physical drive is which, and the ability for ZFS’s own checksumming to actually catch and correct silent corruption instead of the RAID firmware silently masking or mishandling it. Running ZFS on top of a hardware RAID array is a well-known way to get worse reliability than either technology alone, not better - see the RAID redundancy guide on this site for why redundancy and ZFS need to be handled at one layer, not two competing ones.

If you found a used HBA already labeled “IT mode” in the listing, you’re mostly set - skip to the installation section. Most of what shows up used, though, is pulled straight from a server and still in IR mode, or in an ambiguous state, which is where flashing comes in.

Buying the right card

A few things to check before buying, since not every card labeled “9211-8i” on eBay is actually stock:

• Confirm the chipset, not just the model number badge. SAS2008-based cards (9211-8i and its rebadges) are the cheapest and most documented, plenty fast for a dozen SATA HDDs where the drives themselves are the bottleneck. SAS3008-based cards (9300-8i) cost more used but make sense if you’re running SAS3 SSDs or want headroom for a future all-flash pool.
• Check for a heatsink and airflow. These chips run hot enough to need real airflow across them; a card with a bare chip and no case fan blowing over it will throttle or eventually fail. Server pulls usually still have their original heatsink, which is fine, but confirm your case can move air across the slot.
• SFF-8087 vs SFF-8643 connectors. Older cards use SFF-8087 (mini-SAS), which is what most forward breakout cables (SAS to 4x SATA) are built for. Some newer or rebadged cards use SFF-8643. Check what cables you already have or plan to buy before assuming compatibility.
• Avoid true RAID-only cards that can’t do IT mode at all (some low-end “RAID controller” listings are exactly that, with no pass-through firmware available). If the listing doesn’t mention IR/IT mode or a chipset at all, search the exact model number before buying.

Flashing to IT mode: the general process

The specifics vary by exact chipset and motherboard (UEFI vs legacy BIOS matters here), so this is the shape of the process, not a copy-paste script - follow a guide written for your exact card model, since a wrong flash on the wrong chip variant is the one way to genuinely brick these.

1. Identify the exact chip and current firmware. Boot the card’s existing firmware utility (or boot Linux and use sas2flash/sas3flash in list mode) to confirm the chip generation before downloading anything.
2. Download the correct P-series firmware and matching BIOS/UEFI files for that specific chip generation from Broadcom’s own archive, not a random forum mirror if you can help it - a firmware/chip mismatch is the most common cause of a bricked card.
3. Erase the existing (often IR-mode, often OEM-customized) firmware using the flashing utility’s erase command, booted from a small FreeDOS or Linux flashing USB, since most of this tooling doesn’t run cleanly from within a full desktop OS.
4. Flash the clean IT-mode firmware, then flash the matching UEFI or legacy BIOS component so the card’s boot ROM matches the firmware generation.
5. Reboot and confirm the card’s boot-time banner now reports IT mode and lists attached drives individually rather than as a RAID volume.

Two things worth taking seriously here: do not lose power or reset the system mid-flash (a UPS or at minimum a laptop on battery for the flashing session is cheap insurance), and match generations exactly - flashing a SAS3 firmware image onto a SAS2 chip, or the reverse, is the classic way people end up with an unrecoverable card. If a card came from a Dell or HP server, it may also have OEM-specific firmware that needs a full erase before generic Broadcom firmware will take, which is exactly why step 3 exists as a separate step from step 4.

Installing it

Once flashed, the hardware side is straightforward. Seat the card in a PCIe slot with enough physical clearance and airflow, connect SFF-8087/8643-to-SATA forward breakout cables from the card to your drives (not reverse breakout cables, which are for a different job entirely and won’t work here), and power the drives from your PSU’s SATA power rail as normal - the HBA carries data only, not power.

In Proxmox, drives behind an IT-mode HBA show up as ordinary block devices (/dev/sdX or better, /dev/disk/by-id/...) exactly like onboard SATA ports, so they pass into a ZFS pool the same way. In a TrueNAS or Unraid VM under Proxmox, the whole card can be passed through via PCIe passthrough (see the GPU passthrough article on this site for the same IOMMU mechanics, just with an HBA instead of a graphics card) if you want the guest OS to have full, direct control of every drive.

What to skip entirely

Skip actual hardware RAID cards (real “RAID on chip” controllers running RAID 5/6 in firmware) for anything running ZFS or a software-defined array - they’re the wrong tool for that job even used and cheap, for the same reasons IR mode is wrong above. Skip “fake RAID” motherboard chipset RAID (Intel RST and similar) for the same reason if you’re going the ZFS/software route; it adds a layer of ambiguity for no benefit. And skip buying a card with no return policy from a seller who can’t confirm chipset and mode, since a bricked or IR-only card with no path back to IT mode is a genuinely wasted purchase, not just a slightly worse one.

The bottom line

An HBA flashed to IT mode is the unglamorous, unsexy piece of hardware sitting between “my motherboard ran out of SATA ports” and “my ZFS pool can actually see and trust every drive in it.” At $15-40 for a used SAS2008-based card, it’s one of the cheapest, most reliable upgrades in the whole used-enterprise-gear category, and it’s the standard answer for a reason: it does exactly one job, does it invisibly, and gets out of ZFS’s way.