What a UPS is actually protecting you from

Two different failure modes get lumped together as “power problems,” and they call for different responses.

The first is a true outage: the grid goes down and stays down. A UPS here buys you time, nothing more. Once the battery’s spent, everything goes off unless something shuts it down first. This is the case NUT solves.

The second is dirty power: brownouts, voltage sag, a bad surge from a nearby lightning strike, a compressor kicking on and dipping the whole circuit for a second. A decent UPS conditions this transparently, switching to battery for a few seconds or just correcting the voltage, and you never notice. This is the case the UPS solves by just existing, no software involved.

Sizing and NUT matter for the first case. The second case is why you buy a UPS instead of a cheap power strip in the first place, even if you never lose grid power for more than a few seconds a year.

What actually breaks in an unclean shutdown

It’s worth being specific about why a dirty shutdown is worse than “the server was off for a while,” because that’s the part that justifies spending money and time on this.

• Filesystem and database corruption. ZFS is resilient to power loss by design (copy-on-write, no fsck needed), but that protects the filesystem, not necessarily every application on top of it. A database mid-write when power cuts can end up with a corrupted table or a WAL file that won’t replay cleanly. Most of the time it recovers. Sometimes it doesn’t, and you find out the day you actually need that data.
• Proxmox cluster and storage state. A node that vanishes mid-write to shared storage (Ceph, an NFS-backed datastore) can leave things in a state the rest of the cluster has to work out on its own. Clean shutdowns avoid that entirely.
• RAID/array rebuild risk. An array that was mid-resync or mid-scrub when power dropped has to restart that operation, and a marginal read on a second drive during the restart is how a single power event turns into a lost array. Rare, but it’s the scenario every data-hoarder’s nightmare starts with.
• Silent restart failures. Some consumer boards and mini PCs default to “stay off” after a hard power loss unless you’ve explicitly set “restore last state” in the BIOS. A dirty outage plus that one setting equals a homelab that’s still dark when you notice, hours or days later.

None of this is guaranteed on any single outage. All of it gets more likely the more outages you have, which is exactly the kind of risk that’s cheap to eliminate up front and expensive to discover after the fact.

Sizing: watts, VA, and runtime

UPS capacity is sold two ways, watts and VA (volt-amps), and they aren’t the same number. VA is voltage times current; watts account for power factor, which for modern switching power supplies (basically everything in a homelab) runs around 0.9-0.99. A UPS rated “1500VA / 900W” is telling you the real ceiling is 900W, not 1500. Always size against the watt rating, not the VA number on the box.

Step 1: add up your real load. Don’t guess, measure. A Kill A Watt-style meter or a UPS’s own live load reporting (most mid-range and better units expose this through a web UI or management software) will tell you what your gear actually draws, which is usually lower than the sum of every PSU’s rated max. A Proxmox host with a handful of VMs and LXCs pulling 100-150W is typical for a single mini-PC or small tower build; a NAS with 6-8 spinning drives adds another 60-100W, more at spin-up. Add your switch, any USB drives, and anything else on the same circuit.

Step 2: pick a runtime target, not a capacity number. The right question isn’t “how big a UPS can I afford,” it’s “how many minutes do I actually need.” If the goal is a clean, automated shutdown and nothing else, 5-10 minutes of runtime at your real load is plenty, NUT can trigger a shutdown in under a minute of detecting an outage and most hosts finish shutting down well inside that window. If the goal is riding out short outages without shutting down at all (common if you’re on a grid that dips for a few minutes but rarely goes fully dark for long), size for 15-30 minutes instead. Don’t size for hours unless you have a specific reason, that’s a generator-and-transfer-switch problem, not a UPS problem, and a UPS battery big enough to matter at that scale gets expensive and heavy fast.

Step 3: leave headroom, then check runtime at your real load, not the rated load. Manufacturer runtime numbers are almost always quoted at a much lower load than a unit’s max rating, because runtime-per-watt isn’t linear, a UPS run near its ceiling drains dramatically faster than the same unit at half load. If you measured 150W of real draw, check the manufacturer’s runtime chart at 150W specifically, not the headline “up to X minutes” figure, which is usually quoted at 20-30% load. As a rule of thumb, sizing for roughly double your actual load gets you into the flat part of the runtime curve and leaves room to add gear later.

A concrete example: a Proxmox mini PC plus a small NAS pulling a measured 180W combined. A 900W-class UPS (the “1500VA” line most vendors sell at that tier) run at ~20% load will typically deliver well past the 10-minute mark, more than enough for an automated shutdown with margin. Sizing to roughly double your measured load, not your nameplate load, is what actually gets you predictable runtime instead of a guess.

Connectivity: get a UPS with a data connection

The sizing above is wasted without a way for a host to know the power’s out. Buy a UPS with a USB (or network) management port, not a battery-backup-only model. USB is the simplest and most common path for a home setup, plug it into whichever host will run the NUT server, no extra network config needed. Network-managed UPS units (with their own IP and SNMP/web card) are nicer in a multi-host setup, since NUT can poll the UPS directly over the network, but they cost more and are overkill for a single-rack homelab.

Network UPS Tools (NUT): the piece that actually protects you

NUT is the standard open-source way to monitor a UPS and trigger shutdowns across Linux, BSD, and most hypervisors, including Proxmox. It runs in a client-server model:

• upsd (the server) runs on whichever host is physically connected to the UPS (usually via USB) and talks to it through a driver specific to that UPS’s protocol (usbhid-ups covers most modern APC, CyberPower, and Eaton consumer/prosumer units).
• upsmon (the client) runs on every host that needs to react to a power event, including the same host running upsd. It watches the server and triggers a local shutdown when told to.

The basic setup on the host with the USB connection:

1. Install NUT (apt install nut on Debian-based systems, including the Proxmox host shell itself).
2. Identify the UPS with nut-scanner or check vendor documentation for the right driver name, then set it in /etc/nut/ups.conf:

   [myups]
       driver = usbhid-ups
       port = auto
   

3. Configure /etc/nut/upsd.conf to listen (defaults to localhost-only, which is fine for a single-host setup, add LISTEN 0.0.0.0 3493 only if other hosts need to poll this one directly over the network).
4. Set a monitoring user in /etc/nut/upsd.users with a password and the master role.
5. Point /etc/nut/upsmon.conf at that UPS and user, and set MONITOR myups@localhost 1 monuser password master.
6. Set MODE=standalone (or netserver if other hosts will poll this one) in /etc/nut/nut.conf, then start and enable nut-server and nut-monitor.

For every other host that should shut down on the same outage (additional Proxmox nodes, a separate NAS, anything sharing the same UPS’s circuit), install NUT on each, skip the driver/server config, and set upsmon.conf to MONITOR myups@<server-ip> 1 monuser password slave, with MODE=netclient. When the primary host’s upsmon declares the battery critical, every subscribed client shuts itself down too, not just the one physically plugged into the UPS.

Tune the timing, don’t leave it on defaults. upsmon.conf’s FINALDELAY and the UPS’s own low-battery threshold decide how much warning you get before a forced shutdown. If your runtime budget is 10 minutes, set NUT to initiate shutdown well before the battery actually dies, 3-5 minutes of margin is reasonable so a slow-to-shutdown VM or a container with a stubborn stop hook doesn’t get caught out.

Test it before you trust it. Pull the UPS’s input plug (not the battery) with everything running and confirm hosts actually shut down cleanly rather than assuming the config is right. This is the one step people skip and the one that actually matters, a NUT config that’s never been tested against a real outage is a guess, not a safety net.

What this doesn’t solve

NUT gets you a clean shutdown, not continued uptime. If keeping services reachable through an outage matters more than avoiding corruption, that’s a different, much more expensive problem (a generator, a much larger battery bank, or just accepting the downtime). For almost every home setup, a correctly sized UPS plus a tested NUT shutdown is the right amount of engineering for the actual risk, it turns “the power went out and now I’m not sure what state my array is in” into “the power went out and everything shut down exactly the way it would if I’d done it by hand.”