UPS and Graceful Shutdown
Why a dirty power loss is a much bigger deal once ZFS and multiple VMs are in the picture, and how NUT gets everything shut down cleanly before the battery runs out.
A single Docker box losing power is annoying - most containers restart cleanly once power's back. Once you're running ZFS pools and several VMs on Proxmox, a dirty power loss is a bigger deal: ZFS is designed to survive it without corruption (that's part of its value proposition - see Storage and ZFS), but VMs mid-write and databases without proper journaling can still end up in a bad state. A UPS with automated graceful shutdown closes that gap.
Sizing a UPS honestly
Ignore the manufacturer's advertised runtime figure - it's typically measured at a fraction of the UPS's rated capacity, not against your actual load. What matters:
- VA/W rating vs. your actual total load (check the power draw numbers from Power, Noise, and Thermals, now summed across everything on the UPS - the Proxmox host, any networking gear you also want protected).
- You don't need enough runtime to ride out a long outage. The goal is a clean, automated shutdown within a couple of minutes of losing power, not staying online through a multi-hour blackout. A UPS sized for 5-10 minutes of runtime at your actual load is enough for this purpose.
- Buy more capacity than your current load, not exactly enough - UPS batteries degrade over 3-5 years, and headroom now means you're not immediately undersized once that happens.
NUT (Network UPS Tools): the piece that makes shutdown automatic
A UPS with just a USB cable only protects the one machine it's plugged into, and only if something's watching for the "on battery" signal. NUT solves both problems: one machine (the one physically connected to the UPS via USB) runs as the NUT server, and every other machine that needs to shut down gracefully - other Proxmox nodes, if you have more than one - runs as a NUT client, receiving the shutdown signal over the network when the server reports the battery is critically low.
# On the machine physically connected to the UPS
sudo apt install nut
/etc/nut/ups.conf:
[myups]
driver = usbhid-ups
port = auto
desc = "Main UPS"
/etc/nut/upsd.conf and /etc/nut/upsd.users configure who's allowed
to query status; /etc/nut/upsmon.conf on both the server and every
client defines the shutdown trigger (typically "battery critical" or a
configured runtime threshold) and what command to run - on Proxmox,
that's a script that gracefully stops VMs/containers before powering
the host down, not an immediate shutdown -h now that could interrupt
a VM mid-write.
Shutdown ordering with Proxmox
A raw shutdown -h now on a Proxmox host doesn't wait for guest VMs
to shut down cleanly first. Configure upsmon's NOTIFYCMD (or a
custom script triggered by the same event) to instead:
- Trigger a graceful shutdown of each running VM/container (
qm shutdown <vmid>/pct shutdown <vmid>for each guest, in parallel or in a defined order if some depend on others - a NAS VM before the services that mount its shares, for instance). - Wait for guests to actually stop (poll
qm list/pct listrather than assuming a fixed delay is long enough). - Only then shut down the Proxmox host itself.
⚠️ Risk: skipping the "wait for guests to actually stop" step and just sleeping a fixed number of seconds before powering off the host is a common shortcut that works until it doesn't - a slower guest shutdown (a VM mid-backup, for instance) gets killed mid-write anyway, defeating the entire point of the UPS.
A note for clusters
If you're running a multi-node Proxmox cluster (see Proxmox Clustering and HA in Advanced), coordinated shutdown gets more involved - losing nodes in the wrong order can affect quorum before the remaining nodes have finished shutting down cleanly themselves. Worth revisiting this page's approach once you're at that stage rather than assuming the single-host script above scales as-is.
Next: Proxmox Backups.