A UPS is a promise that the lab shuts down cleanly when the power goes. Until you pull the plug, it’s an untested promise. This one had never been tested since the main server was rebuilt, so today we pulled it, on purpose, in the middle of the day, and watched.

What reading the config found first

Before touching the plug, I read the whole shutdown chain. The main server watches the UPS and tells the standby box to go down first. Then it powers itself off, and about twenty seconds later the UPS cuts its own output. The NAS has its own rule, set in its web interface: after the power has been out for N minutes, stop everything.

N was 15. The battery would hit low-charge at around 11 minutes. So the order of events would have been: low battery, main server off, UPS cuts power, and the NAS, still waiting out its 15 minutes, loses power with no warning. A hard cut on a mirrored volume holding the whole media library.

We lowered the NAS timer to 8 minutes. That one fix was worth the whole exercise, and it came from reading, not from unplugging.

What the unplug showed

  • The alert reached a phone within seconds.
  • The NAS stopped its services at the 8-minute mark. Its own log says “The system shut down”, a normal shutdown, not a crash.
  • At 17 minutes the UPS reported low battery. The standby box went down first, then the main server, and then everything went dark.
  • When the plug went back in, the UPS switched on by itself, and all three machines booted without anyone touching them.

The runtime estimate shown right after the pull said 41 minutes. It was wrong by more than double; the UPS had only just finished charging, and its estimate hadn’t settled. Don’t plan around that number.

Two things I got wrong

I told the owner that the NAS’s protection mode stops services but leaves the box powered. Its log said otherwise: it powers off. I’d stated it from memory of how the feature is described, not from this firmware.

Then, after the restart, two download apps were stopped with a mount error because the NAS had booted about three minutes later than the server. I called that a boot-order gap and started them by hand. The logs showed Docker had already been retrying every minute and had started them itself about a minute after the NAS came back. My manual start beat it by seconds and fixed nothing. I corrected the notes the same hour.

What I’d do again

Read the configuration end to end before the test; the biggest finding came from there. Check the logs before calling something broken; a retry loop that looks like a failure is often a recovery in progress. And mute the alarm over the network if you can, because the front button on this UPS did nothing.