Can a Home Server Resume Services in Dependency Order After UPS Recovery?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Can a Home Server Resume Services in Dependency Order After UPS Recovery?

Yes, but only when the dependency graph is explicit. A server can power on automatically after UPS recovery while applications still fail because storage, DNS, databases, or networks are not ready.

Process start order is not the same as service readiness. Use systemd dependencies for host-level resources and health checks for containers and applications. That distinction determines the safe configuration, validation method, and rollback point.

Write the dependency graph before automating it

List the chain from power and network through encrypted disks, NAS mounts, container runtime, databases, application services, and reverse proxy. Mark which dependencies are local and which live on another server.

Give every stateful dependency a readiness signal: mounted path, database query, DNS lookup, or application health endpoint. Avoid fixed sleeps because recovery time changes after an unclean shutdown.

Define a bounded failure state so a missing NAS does not cause an application to write into an empty local directory.

Coordinate each control layer

Use systemd `After=` and `RequiresMountsFor=` relationships for host services and remote mounts. Make the container stack unit depend on Docker and the required mount units.

Within Compose, add real health checks and use `depends_on` with `condition: service_healthy` where supported. Applications should still retry database connections because dependencies can fail after startup.

Use the table below to assign each dependency to the layer that can actually observe it.

Observed state	Verdict	Next action
Disk and NAS mounts	systemd mount dependencies	Gate stateful services
Database ready for queries	Container health check	Gate applications
External app reachable	Application retry plus monitoring	Do not use fixed sleep

Design recovery across two servers

Start the storage or infrastructure server first, then wait for exported shares and databases to become healthy before releasing application services on the second host. UPS software should not merely power both hosts on simultaneously.

The ZimaSpace article on UPS signals and virtual machines shows why the control chain crosses layers.

An independent systemd and Compose guide explains boot and shutdown ordering races.

Keep a manual cold-start runbook for the case where automation stops at a failed health gate. It should name the check, expected timeout, safe retry, and owner of each service.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Test the full UPS recovery state

Stage a controlled shutdown on battery, restore AC, and capture timestamps for host boot, mount readiness, database health, application health, and proxy availability.

Repeat with a delayed NAS and with a database recovery that takes longer than normal. Services should wait or fail visibly rather than start against missing state.

Proceed when both normal and delayed recovery preserve order and data paths. Stop if restart policies bypass readiness, applications write to fallback directories, or a dependency has no measurable health signal.