Recovering a Remote Mac Mini

Blue line illustration of a recovery-test desk with two laptops, a large display, keyboard, mouse, and fan.

A stylized view of my development setup for this saga.

Much of my (software) development work happens on a Mac mini at home, even when I am somewhere else. I connect from a Chromebook or MacBook over SSH, and tmux keeps my terminal sessions available when the connection drops. That arrangement works well... until the Mac mini itself loses power.

What does a nerd do in this case? Buy a big-ass battery.

More precisely, I bought a UPS (an "uninterruptible power supply") to help. It powers the Mini, a network-attached storage system (NAS) that holds my Time Machine backups, and the local networking they need. A brief outage should leave everything running; a longer one should give the Mini and NAS time to shut down without corrupting data. But because I use the Mini remotely, shutting down safely was only half the job. It also had to turn itself back on so I could reach it again. (cue dramatic music...)

Blue line illustration of an upright UPS with labeled power and menu controls, an LCD status display, and USB ports.

The UPS controls and display, illustrated.

When the Power Comes Back

Both the Mini and NAS are configured to start themselves after power is lost and then restored. Normally that makes recovery straightforward: power disappears, the machines shut down, power returns, and they start again.

The UPS complicates that sequence.

When wall power fails, the UPS initially just runs the Mini and NAS from its battery. If wall power returns soon, nothing shuts down. If the outage lasts past a configured cutoff, both machines begin a clean shutdown.

The tricky case is when the outage lasts long enough to trigger those shutdowns, but wall power returns while the UPS is still supplying power from its battery. The UPS simply switches back to wall power without interrupting its outlets.

From the Mini's point of view, power never disappeared. It shut down while its outlet remained energized, so it never saw the power-loss-and-return event that tells it to start again. Wall power can be fully restored and the Mini will happily sit there powered off indefinitely.

So, to get the machines to shut down cleanly and start themselves again when wall power returns, I had to programmatically ensure that their outlets actually turn off after shutdown and then turn back on when utility power is available. That creates the missing power transition: the Mini finally sees power disappear and return, and starts itself again.

If wall power returns before shutdown becomes necessary, the equipment simply keeps running.

All this sounds fine, but how do I test such madness? I decided to test a simple lamp before connecting the computers. When wall power remained out, the UPS turned its outlets off and kept them off. When wall power had already returned, it turned the outlets off briefly and then back on. The lamp let me verify both outcomes without risking the computers or their storage.

I used Network UPS Tools (NUT) to read the UPS over USB and share its status with the NAS. I also wrote a small service on the Mini to implement the shutdown policy. It tracks whether an outage is still short enough to cancel or has crossed the point where shutdown and the eventual outlet cycle must complete.

The shutdown controller gives the NAS time to finish writing and power off, checks that the UPS is still reporting fresh and sensible data, schedules the outlet cycle, and shuts down the Mini. It also records enough state to avoid blindly repeating a power-cycle request whose outcome is uncertain. If it cannot verify the UPS's status, it refuses to order a blind power cut—even though that means the battery could eventually run out.

Tests with actual computers confirmed the sequence: brief outages left the equipment running, while longer ones allowed both computers to shut down and restart, including when utility returned before the UPS had cut its output.

The tested power path uses a CyberPower CP1000PFCLCDa with firmware CR01803F5C11 and Homebrew NUT 2.8.5. NUT's usbhid-ups 0.71 driver selected the CyberPower 0.85 subdriver.

Getting Back to Work

SSH is not exposed through a public port-forward. My MacBook and Chromebook reach the Mini through Tailscale, a private network built on WireGuard. Its access policy allows only those two enrolled recovery devices to reach the Mini's SSH service.

Each client has its own SSH key. Each also stores the expected cryptographic identities of the Mini's preboot and normal SSH services, so it will reject an impostor instead of silently connecting to one. After a normal boot, the Mini accepts SSH keys rather than an account password.

I also needed that private connection to come back without anyone at home repairing the network. I deliberately powered down networking beyond the UPS-backed group and confirmed that the Tailscale connection returned on its own when that equipment restarted. (The test did not simulate a failed modem or an ISP outage. I am lazy.)

FileVault deliberately stops the normal macOS boot until someone unlocks the encrypted disk. MacOS provides a limited preboot SSH service for that purpose: it accepts the password of a FileVault-enabled account, unlocks the disk, and disconnects. It does not provide a shell. Normal macOS then boots, and the regular key-only SSH service starts.

I put a small recovery helper on each client. Its workflow looks like this:

Check for life: It first tries normal key-only SSH in case the Mini has already booted.
Wait for the private network: Otherwise, it waits for the private Tailscale path and preboot SSH service.
Interactive unlock: It asks me to confirm one unlock attempt and prompts me to type the FileVault password directly into SSH's interactive prompt. (It never stores the password or places it in a command).
Monitor the transition: The expected disconnect after unlocking is treated as a transition, not proof that recovery is complete.
Reconnect and resume: The helper waits for normal key-only SSH to return, prompts separately for the login Keychain if needed, and then attaches to a tmux session.

Crucially, this process does not weaken SSH host checking or turn the FileVault password into a general remote-login credential.

I tested that process from outside the house after separate reboots, once from the MacBook and once from the Chromebook. In both cases I remotely unlocked the encrypted disk and reached a usable development session while the Mini at home remained at its normal login screen. Nobody had to be there to unlock it for me.

What Recovery Means

This is not unattended recovery. After the Mini restarts, FileVault still requires me to unlock the disk before normal macOS, NUT, and the shutdown controller can run again. A second outage during that interval remains an awkward edge case. But engineering is ultimately an art of tradeoffs, and I’m comfortable trading absolute automation for pretty solid security guarantees and usability.

The larger lesson was that battery backup, clean shutdown, restart, and recovery are different things. A UPS solved the first problem. The rest took explicit policy, testing, and a way to prove that the machine on the other end was actually usable again.

Note: There is also a small suite of code behind all this that currently has an audience of one (me). I’m considering turning it into something other people could actually use, with the cleanup, documentation, testing, and setup guide that would require. If that sounds useful to you, let me know—it would be a good reason to do the less interesting work that separates “works at my house” from “worth publishing to help others.”