UPS and clean shutdown: the forgotten link in every homelab

Key takeaways

• Without monitoring software, a UPS merely postpones the hard power loss by a few minutes.
• You need a monitoring service that triggers the shutdown at a threshold, not when the battery runs flat.
• Shutdown order matters: the machines that consume storage go first, the storage goes last.
• The classic trap: shutting down the server that drives the UPS before the others, which then lose their source of information.
• A battery has to be tested: it ages, and it can end up holding for a few seconds with no indicator light saying so.

The UPS is often the last piece of equipment bought and the least configured. You plug it in, the LED is green, and the subject is closed.

Then a forty-minute outage arrives. The UPS holds for eight minutes, nobody triggers anything, and everything dies hard, exactly as if it were not there.

What a UPS does without software

On its own, a UPS protects against three things: momentary outages, voltage fluctuations, and surges. That is already worth having, and it is enough to justify the purchase.

But faced with a long outage, all it does is postpone the hard shutdown. When the battery empties, everything drops at once, in the middle of whatever writes were in flight.

Real protection comes from the monitoring service: software that talks to the UPS, watches the state of the battery, and triggers an ordered shutdown while there is runtime left.

Without that piece, you bought a delay, not protection.

The trigger: a duration, not a percentage

The first question is: at what point do we start shutting down?

The reflex is to settle on a battery percentage. The right criterion is a different one: it is the time your installation needs to shut down completely.

That duration is measured, not estimated. Time how long your slowest machine takes to power down. A hypervisor cleanly stopping a dozen virtual machines often takes several minutes. Add a margin, and trigger at a level that guarantees that window.

The classic mistake is a threshold set too low, chosen to "get the most out of the battery." The shutdown starts, the battery runs out before it finishes, and the machines die mid-write. You end up with the worst of both worlds: the complexity of a shutdown sequence and the corruption of a hard power loss.

Shutdown order

With several machines, the order is not a matter of indifference. The rule: storage consumers first, storage last.

If your NAS powers off while a hypervisor is still writing to it, you cause precisely the corruption you set out to avoid, and you make it worse, since the writes are cut short by a disconnection rather than by a power loss.

The sane sequence:

1. Virtual machines and containers, stopped by their hypervisor.
2. The hypervisors themselves.
3. Shared storage.
4. Network equipment, if it is on the UPS.

Each step needs a delay before the next, calibrated on the real shutdown time of the previous tier. Here again: measure rather than estimate.

What to plug in, and what not to

Two cabling mistakes come up again and again.

Forgetting the network. A UPS that powers the servers but not the switch produces an absurd situation: the machines are running, the monitoring wants to trigger the shutdown, but nothing can talk to anything. The switch and the router draw very little; they belong on the UPS.

Plugging in things that have no business being there. A laser printer can pull a considerable amount of power at start-up, well beyond what a consumer UPS can take. It has no place on the protected outlets: it eats into usable runtime and can trip a protective cutoff at the worst possible moment.

The battery ages in silence

This is the most neglected point. A battery loses capacity with time and heat, and that degradation is invisible.

A UPS can report a perfectly normal state and in reality hold for only a few seconds under load. You find out at the next outage, which is too late.

An annual discharge test, under real conditions and timed, is the only way to know your effective runtime. It is also your chance to verify that your shutdown sequence behaves as designed: in what order, in how long, and whether everything comes back up correctly afterwards.

Do it at a moment of your choosing, with fresh backups. A test that uncovers a problem is a successful test.

Startup, the forgotten half of the problem

Shutdown is the visible part; the return of power raises its own questions.

Do your machines restart automatically? The relevant setting lives in the firmware and often defaults to "stay off", which for a server is rarely the behavior you want.

Do they restart in the right order? A hypervisor that boots before its storage finds its volumes missing and may flag machines as failed. Staggered power-on delays settle the question.

And above all: what happens if power comes back during the shutdown sequence? That disconcerting case, where the outage was brief but the shutdown was already under way, has to be planned for, or you end up with an installation half powered down and half started up.

Key takeaways

A UPS without monitoring is a delay, not a protection. The software, the shutdown order, a threshold computed from measured durations and the annual battery test are what turn a purchase into a guarantee. It is very little work, and it is the difference between an outage with no consequences and a full restore on a Sunday night.