From Hardware RAID to ZFS on My R720xd

My server thinks it’s an R720.

The firmware says “PowerEdge R720”. But the front has 24 drive bays and the back has two more, and only the R720xd has that layout. So it’s an xd with an identity crisis. Relatable, honestly.

Last night I pulled its hardware RAID card, put in a Dell HBA330, and reinstalled Proxmox on ZFS. I bought zero new drives. Here’s what it looked like before, what I did, and how it went.

Hardware usually has opinions. This time it mostly kept them to itself.

Swipe to pan

Title

The storage path, before and after

Scale

NTS

Rev

B

Date

2026-09-29

Dwg no

TD-LAB-02 · FIG 1

Before: the RAID card was hiding things

The server ran a PERC H710P Mini, Dell’s hardware RAID card. It took the physical disks, grouped them into virtual disks, and handed Proxmox only those. Proxmox put LVM-thin on top and never saw a real drive.

That’s fine until you want ZFS. ZFS wants raw disks so it can checksum every block, run its own mirrors and take its own snapshots. It can’t do that through a card that’s pretending.

Turns out the card was also hiding problems.

Before touching anything, I had an AI agent inspect the box, read-only. It dug through the logs and came back with this:

• In late August, the PERC reset both of my Gigastone SSDs and logged one of them as “not functioning correctly” and then “removed”. It was all sitting in the iDRAC’s lifecycle log.
• Both Gigastones still passed SMART, with 6 and 22 reallocated sectors. Not dead. Just not trustworthy.
• One of the two 15k SAS drives in the back, half of the RAID1 that Proxmox booted from, reported “HARDWARE IMPENDING FAILURE” with 16 grown defects.

So the boot mirror was one bad day away from being a boot drive, and two SSDs were quietly getting kicked out by the card. Cool cool cool.

Drive	Health before the swap	Now
2× Gigastone 256 GB SSD	SMART passed; 6 and 22 reallocated sectors	rpool, bays 0 and 1
Seagate ST300MP0004, 300 GB 15k SAS	0 defects, about 55,500 hours powered on	rpool, rear bay 24
2× Crucial MX500 500 GB SSD	passed; 64% and 90% life left	fast, bays 2 and 3
Crucial MX500 1 TB SSD	passed; 84% life left	bulk, bay 4
Seagate ST9300653SS, 300 GB 15k SAS	”HARDWARE IMPENDING FAILURE”, 16 grown defects	out of rear bay 25, for good

Proxmox 8 went end of life in August, and everything on the old install was disposable. A clean reinstall cost me nothing.

The card

The HBA330 (Dell part J7TNV) is an LSI SAS3008 at 12 Gb/s in pass-through mode. No RAID, no virtual disks, no opinions. Every disk shows up as itself.

The catch: Dell doesn’t list the HBA330 for the R720 or R720xd. But it’s the same chip and the same Linux driver (mpt3sas) as the widely used LSI 9300-8i. So Linux seeing it was a safe bet. Booting from it was the open question.

Three pools, no new drives

I didn’t buy drives for this. Everything in the box that was still healthy got a job.

Swipe to pan

Title

Three pools, no new drives

Scale

NTS

Rev

B

Date

2026-09-29

Dwg no

TD-LAB-02 · FIG 2

• rpool holds Proxmox itself and ISOs. It’s a 3-way mirror: both Gigastones plus the good 15k SAS drive. About 220 GiB usable.
• fast holds VM disks. It’s a mirror of the two 500 GB MX500s. About 450 GiB.
• bulk is scratch and sandboxes. The 1 TB MX500 on its own, about 930 GiB. Losing it costs nothing.

Why three disks just to boot? Because I don’t trust the Gigastones. They were flaky behind the old card, so the healthy SAS drive is a third copy. If both Gigastones die, the server still runs and still boots from the SAS drive.

Is a mirror of two sketchy SSDs and a 15k spinner what a storage textbook would draw? No. It’s what I have.

Swipe to pan

Title

Bay map, as built

Scale

NTS

Rev

B

Date

2026-09-29

Dwg no

TD-LAB-02 · FIG 3

Every drive went where that map says. The failing one isn’t coming back.

The installer’s 10% rule

The Proxmox installer has opinions too. It refuses to build a mirror if the disks differ in size by more than 10%. The error literally says “Mirrored disks must have same size”.

The Gigastones are about 238 GiB each. The SAS drive is about 279 GiB, roughly 17% bigger. So the installer said no.

Swipe to pan

Title

Mirror members, to scale

Scale

TO SCALE

Rev

B

Date

2026-09-29

Dwg no

TD-LAB-02 · FIG 4

So Proxmox 9.2 went onto the two Gigastones only. After that, the SAS drive was attached as the third copy, with its own boot partition.

Two more tricks. The boot pool is capped at 220 GiB, so any SSD of 240 GB or more can replace a boot disk later. And during the install, every other drive was slid 2–3 cm out of its bay. The installer pre-selects every disk it sees; this made erasing the wrong one impossible.

Lazy-proofing. My favorite kind.

Two cables, 26 bays

The HBA330 has two ports. The server has three SAS cables. That math bugged me for a minute.

The third cable never went to the controller. It runs from the front backplane to the two rear flex bays. The front backplane has a SAS expander that feeds all 24 front bays and the 2 rear ones, so two cables from the card reach all 26.

Swipe to pan

Title

Two cables, 26 bays

Scale

SCHEMATIC

Rev

B

Date

2026-09-29

Dwg no

TD-LAB-02 · FIG 5

The old card’s cable didn’t get moved, it got pulled: the mini PERC has no cable ports, so its cable starts at the system board. Two new cables run from the HBA330 to backplane SAS A and SAS B. The flex-bay cable stayed put.

Me and the agent

The runbook split every step into two columns: You (me, with hands) and Agent (the AI, over SSH, after I say go).

Stages 0 to 9 were mostly mine: shut down, pull the card, cable, close up, sort the drives, install. There’s no virtual console on this server’s management licence, so the install happened on a real VGA monitor and a USB keyboard. A VGA monitor. In 2026.

Once I said “Proxmox is up”, stage 10 was the agent’s: check the card’s firmware, attach the SAS drive to rpool, create fast and bulk, and write down which bay holds which drive.

Swipe to pan

Title

Me and the agent, step by step

Scale

NTS

Rev

B

Date

2026-09-29

Dwg no

TD-LAB-02 · FIG 6

It can’t pull a drive. That part is still my job.

How it went

Short version: boring. The good kind.

• Drives. Every one landed in its planned bay.
• Fans. A Dell server can crank its fans when it sees a PCIe card it doesn’t recognize. Mine didn’t. They stayed right at the old baseline. No jet engine.
• Firmware. The card’s firmware was already current. No flashing. The best step is the one you get to skip.
• Boot. UEFI boot worked, so the legacy-BIOS fallback stayed in the drawer. All three rpool disks can boot the server, so any one of them can die and it still comes up.

Two surprises

Nothing broke. Two things were just weird.

The Gigastones are twins. Both report the same serial number. And the same WWN, which is supposed to be unique worldwide. Linux builds its stable disk names under /dev/disk/by-id from exactly those, so two disks got one link between them. So the pool names those two by bay path instead: the route through the card to the bay each one sits in. The bay map stopped being just tidiness. Move a Gigastone and it shows up under a new name.

No blinking lights. Behind the HBA330, Linux gets no enclosure support, so there’s no command to blink a bay’s locate LED. The bay numbers still come through from the SAS layer, which knows where each disk is plugged in even though it can’t light one up. If a drive dies, I’ll find it by number. And by counting.

What’s next

A couple of hours later, a three-node Talos cluster went on top of fast. That’s a whole other drawing: the stack.

Next is getting that cluster to do something useful. What, exactly? Not decided yet. It’s a homelab.

The full drawing of the server, bays and cables and all, is on Sheet 02.

TD-LAB-02 · Sheet 2 of 3 · Rev B · Checked TD The server The R720xd inside and out, after the PERC H710P Mini → HBA330 swap. Open Sheet 02 →

Hardware RAID: retired. ZFS: in charge. The server: still convinced it’s an R720.