AmeriBrit 20U Rack
Media / Game / Cloud

Storage ports and bays

The board has six SATA, but the M.2 socket disables SATA 5/6 when populated — and it is populated, since the SK Hynix NVMe is the boot drive. That trade is already made, not hypothetical. The GPU takes the only x16 slot, so an LSI HBA is off the table and the x1 SATA card is the workaround.

The five drives on hand fit with room left. They use six of seven bays and six of eight ports, so there is one bay for a sixth drive. After that, bays bind before ports do — the eighth port would have nowhere to put a drive.

Boot costs nothing in this budget: the NVMe sits on the board, using no port and no bay. Growing past six HDDs means the NAS, not this chassis.

19 TB raw, and no parity. Two 8 TB drives plus three 1 TB. Nothing here is redundant — a drive failure loses whatever was on it, which is the argument for the NAS running SnapRAID rather than the media server growing indefinitely.

The three 1 TB drives are worth reconsidering. Each costs a bay and a port to contribute 1 TB, and consolidating them into one larger drive would free two of each — the scarce resources in this chassis are physical, not capacity.

Power draw

750 W puts you near 43% load, right by the Gold efficiency peak. A 550 W would have saved $50 but leaves no room for a future GPU.

UPS headroom

The CyberPower is 1000 W and could carry all three at about 65%, with even a simultaneous cold boot inside the envelope. Note the 1500 VA figure is not the constraint — active-PFC supplies run a power factor near 1.0, so the 1000 W rating is what binds.

It should not have to. Moving the game server to the BR1000MS drops this to ~475 W and takes runtime from roughly five minutes to ten — see the office split below. The figures above are the all-on-one case, kept as the ceiling to design against.

Runtime, not capacity, is the limit either way. Ten minutes is a graceful-shutdown window, not a ride-through — worth wiring up NUT or apcupsd before you rely on it.

Adding the NAS later pushes typical toward 770 W, around 77%, which is where headroom starts to matter. The 2000 VA version of the same unit is $449.95, so about $90 buys that margin if the NAS is a certainty.

The interim APC is only 600 W. It carries the media server alone comfortably and two servers at idle with little to spare, but a simultaneous cold boot overruns it — exactly what happens when utility power returns after an outage. Until the CyberPower lands, stagger the boots in BIOS or run the game server straight off the wall. It is the one box whose sudden loss costs nothing.

Splitting the office load

Never plug one UPS into another. The downstream unit's charger looks like a nonlinear load with real inrush to the upstream one, most manufacturers forbid it, and the runtimes do not usefully add. Both office units hang off the wall independently.

Leaving the BR1000MS on 30 W of network gear wastes it. It is pure sine, so it is one of only two units in the house allowed to carry a server — and hours of network runtime buy little once the servers are already down. Put the game server on it.

The media server's runtime roughly doubles, from about five minutes to ten, which is the real prize. Both units land near half load, which is where their batteries last longest and run coolest.

The game server is the right one to move: it holds nothing that a sudden loss would damage, so pairing it with the older battery costs the least. Media and cloud — the two that hold data — stay on the newer, larger unit.

This does mean two shutdown paths. Each UPS needs its own USB run to something that can act on it: BR1000MS to the game server, CyberPower to the media server, with the cloud server running a NUT client pointed at the media server. One UPS with one cable is simpler; that simplicity is what you are trading for the extra five minutes.

Coming back up

Shutting down cleanly is the easy half. Coming back on is two separate settings, and neither is on by default.

1 · BIOS: restore on AC power loss. Set it to Power On, not Last State.

Last State reads as the safer option and is the wrong one here. NUT shut the box down cleanly, so the last state is off — and it stays off.

2 · The UPS has to actually cut its outlets. This is the step that gets missed. NUT's shutdown must finish by telling the UPS to drop the load, so it re-energises when mains returns — shutdown.return, issued by upsdrvctl shutdown at the end of upsmon's sequence.

Without it, the failure is specific: power comes back before the battery is flat. The outlets never de-energised, the servers never see an AC transition, and they sit there off until someone walks over and presses a button. A battery running all the way down does the right thing by accident — you do not want correct behaviour to depend on the outage being long enough.

Confirm each unit supports it before relying on it, because CyberPower's NUT load-shed support is less consistent than APC's: upscmd -l cyberpower should list shutdown.return.

3 · Test it the long way. Pull the plug and leave it — all the way down, outlets dead, then restore mains. Cutting the test short at "they shut down" only proves the half that was already easy.

Nothing on the monitoring panel can verify this. It sees a broken shutdown path; it cannot see a server that would never come back, because that only shows up during the one event you are building for.

WAN headroom

1 Gb symmetric is the enabler. Most residential plans give a fraction of that upstream, which is what usually makes self-hosting painful. Remote Jellyfin is the only real consumer:

The RTX 3050 runs out before the uplink does. NVENC handles roughly 8–12 simultaneous 1080p transcodes, so the GPU caps you well below the line. More bandwidth would not buy one extra stream.

Everything else is noise: game servers are 10–50 kbps per player, Immich sync is inbound and bursty, restic is incremental after the first seed and runs overnight.

The constraint worth watching is the mesh backhaul, not the plan — see the network design. Two wireless hops could hold the rack to 200–400 Mbps no matter what you pay for.

Sizing the panel VPS

2 vCore, 4 GB, 40 GB NVMe at $5/month. The instinct is that 40 GB is tight for a metrics database. It is not the constraint.

Even with the retention job never written, four hosts generate roughly 2 GB a year. That is a decade of headroom on 40 GB. Pruning still matters — but for query speed and index size, not for disk, and it is worth being clear about which problem you are solving.

4 GB is comfortable for Postgres, Caddy and the panel itself. The panel is a Rust binary in the tens of megabytes resident, so the database gets essentially all of it. Two cores are idle most of the time: a handful of agents posting every 15 s and an alert sweep every 60 s is not a workload.

Two things would break this sizing, and neither is planned: shipping logs to the panel rather than just metrics, or keeping full-resolution history for a year instead of rolling it up. Both are disk problems, and both are decisions rather than surprises.

Airflow

One 120 mm in (~70 CFM), two 80 mm out (~80 CFM) plus PSU exhaust. Slightly negative pressure.

Not a thermal problem — intake pulls through the drive cage, cooling the HDDs on the way past. It is a dust problem: unfiltered air enters through every seam. Blow the chassis out every few months.

If the P12 Pro has to run loud to hold GPU temps, drop to one rear P8 Max. Less exhaust, closer to neutral, quieter.

PCIe slots

One x16 (GPU) plus x1 slots. Two x1 cards want those slots: the SATA card and the NIC.

Verify the exact x1 slot count on your board before ordering both. If there's only one usable slot after the dual-slot GPU, something has to give — most likely the SATA card, with bulk storage moving to the NAS instead.

10 GbE is not possible here. It needs x4 or x8. 2.5 G over x1 is the ceiling.

Fan control on Debian

The hub is a dumb splitter, so lm-sensors and fancontrol drive it through the motherboard header. The real obstacle is the Super I/O driver.

Nuvoton chips need acpi_enforce_resources=lax at boot. ITE chips need the out-of-tree it87 module via DKMS — the frankcrawford fork is the maintained one.

Run sensors-detect after the build. If pwmconfig finds no PWM outputs, that's the ACPI lock, not the hardware. Fallback: set a conservative fixed curve in BIOS and move on.

Wiring the fans

Cooler stays off the hub so it tracks CPU temp independently. The hub reports RPM from slot 1 only — put the intake there, since it's the fan whose failure matters most.

Every server is dual-homed

Onboard gigabit to the GS116 for internet, SSH, web UIs and management. A second 2.5 Gb card to the island, where applicable, for NFS, Immich originals and restic.

Main LAN addressing is DHCP from the eero — reserve a fixed lease by MAC for every server so hostnames stay stable.

The rack sits four hops out

Modem to Bedroom to Kitchen to the BrosTrend switch, which fans out to the Eufy HomeBase 3 and to the Office eero. The Office unit then feeds the whole rack.

That makes the BrosTrend a single point of failure for everything in the rack. It is a $38 unmanaged switch carrying the entire WAN path — if it dies, the rack loses internet even though every eero is still up. Worth keeping a spare in a drawer; it is the cheapest insurance in the build.

It is at least on battery, sharing the BE850M2 with the kitchen eero and the Eufy, so a power cut does not take it out. Note this is the second reason that unit matters more than its size suggests.

Worth confirming the backhaul is wired. These are dual-band, so there is no dedicated backhaul radio — on a wireless mesh each hop shares airtime with clients, and this far out the rack could see well under half the 1 Gb service. Wired, it is a non-issue.

Note there are two 2.5 Gb switches in play. The Kitchen BrosTrend is ordinary LAN and carries the rack's uplink. The rack one is the isolated island and must never be confused for it.

Cable colours

Blue for main LAN, server onboard NICs to the GS116. Green for the storage island. White or red for the eero uplink.

Uniform correct lengths matter more than cable spec. Avoid Cat 7 and Cat 8 — marketing labels at these speeds — plus flat cable, braided jackets, and anything not stating bare copper.

What this gives up

The gaming tower and every Wi-Fi client reach the NAS at 1 Gb, since they arrive through the GS108 and GS116 rather than the island. Fine for occasional access, noticeable if you regularly pull large media off the NAS.

The fix is a 2.5 Gb card in the tower and a run to a reserved island port, or an 8-port island switch (~$60) to cover that and the future servers. Nothing here blocks either.

Three bundles, one side each

Power runs down one rear post, data down the other, exactly as the build order calls for. Drawing them as one bundle per service is the point — a cable you can trace by colour and side is one you can unplug at 2am without tracing it at all.

Hovering a device dims everything else, which is the quickest way to see what a given box actually depends on.

The APC sits on the floor beside the rack rather than in it, so the game server, GS116 and network shelf runs leave the frame at the bottom rear and terminate there. The 2U reserved for the second CyberPower stays empty until that swap happens.

Service loops are not drawn

Every run here is the straight-line path. Real ones need the 6–8″ of slack the build order specifies, so a chassis can slide out on its rails without unplugging.

That slack is why the 5 ft patch cables are more forgiving than the 1–2 ft the network design asked for, and also why they will coil behind the posts.

The network shelf

2U carrying the GS108, the 2.5 Gb island switch and the office eero. None of the three earns a U of its own, and the eero is taller than 1.75″, so a single U would not have cleared it. The GS116 nearly fills 19″ by itself and keeps its own.

Dropping the PDU paid for the second U. One 2U bay remains genuinely spare, and the bottom 2U is reserved for the second CyberPower rather than sitting empty. Everything still adds to twenty.