What Should Happen to Your Homelab During a Power Outage?
Tech GuruA homelab should fail in a predictable order: keep the network alive first, shut down storage cleanly, stop compute before batteries are exhausted, and restart services only after power is stable. A UPS is not just backup power; it is a controlled shutdown system.
Design principle: Power planning is an operations problem: measure real watts, choose shutdown order, and spend money where runtime or clean shutdown changes the outcome.
The Short Version
- A homelab should fail in a predictable order: keep the network alive first, shut down storage cleanly, stop compute before batteries are exhausted, and restart services only after power is stable. A UPS is not just backup power; it is a controlled shutdown system.
- Use the decision matrix below, then prove the result with the validation checklist before making it the default.
Why This Matters Now
A power plan starts with dependency order and the measured load, not the UPS label. The ONT, router, core switch, one access point, and DNS keep the home reachable; the NAS and hypervisor need shutdown margin; nonessential virtual machines can stop first. Record which shutdown client receives the utility-loss event and which systems must remain alive long enough to act on it.
Short outages usually hurt network access first; longer outages threaten storage consistency and battery runtime.
Routers, ONTs, switches, and DNS often need less power than NAS and compute nodes, so they belong on the highest-priority runtime budget.
A UPS with USB or network signaling is more useful than a larger battery that cannot tell systems to shut down.
This guide converts the device inventory into runtime groups, UPS signaling, shutdown thresholds, a controlled outage check, restart order, and an annual energy estimate. The design passes only when the network follows its priority, storage and compute record clean stops with battery margin, and DNS and storage return before dependent applications; an LCD runtime prediction alone cannot establish that sequence.
Recommended Baseline
Start by measuring real wall power. The router, modem or ONT, core switch, one access point, DNS, NAS, and compute host should be listed separately where possible. Then decide what must stay online and what should shut down first. For most homes, network gear gets the longest runtime, storage gets a clean shutdown, and compute stops before it drains the UPS.
The baseline is a UPS with signaling, documented shutdown thresholds, alerts that work during partial outages, and a restart order that brings DNS and storage back before dependent apps. For electricity-cost planning, the baseline is the annual cost of always-on watts, not the peak rating on a power supply.
Decision Matrix
| Choice | Best Fit | Watch Point |
|---|---|---|
| Small UPS for network | Router, modem/ONT, switch, access point, DNS box. | May not protect NAS or servers. |
| Larger UPS for NAS/server | Clean shutdown for storage and virtualization. | Costs more and needs battery maintenance. |
| Separate UPS units | Network stays online while compute shuts down. | More devices to monitor and replace. |
| No UPS | Only acceptable for disposable labs. | Higher risk of corruption, downtime, and manual recovery. |
Decision Worksheet
Fill the worksheet with observed wall watts for the ONT, router, switch, access point, DNS host, NAS, and compute node; then add outlet grouping, UPS watt limits, the USB or network signaling path, shutdown and startup dependencies, alert delivery, and acceptable runtime. Do not substitute a product-page estimate for the actual combined load and the battery condition in your installation.
| Worksheet Item | What To Write Down | Why It Matters |
|---|---|---|
| Primary question | What should happen to my homelab during a power outage? | This keeps the article tied to the reader's real decision instead of drifting into a generic product comparison. |
| Affected systems | ONT or modem, router, switch, access point, DNS, NAS, compute hosts, UPS batteries, and alert delivery. | Readers should know who and what they are protecting before they choose hardware, software, or a cloud service. |
| Failure model | Utility loss, brownout, exhausted battery, no shutdown signal, stale UPS battery, and bad restart order. | Different failures need different controls. This row prevents RAID, sync, VPN, or MFA from being treated as magic. |
| Proof test | Run a controlled outage test and record alert timing, shutdown timing, runtime, and restart order. | A recommendation is not proven until it survives a small, repeatable test using realistic data, clients, or accounts. |
| Rollback path | Return noncritical devices to normal power or old shutdown settings if the UPS cannot support the planned load. | A reversible change is less stressful, easier to explain, and less likely to turn a weekend project into an outage. |
| Measurement to capture | Measured wall watts for each always-on device under normal load. | Numbers, logs, screenshots, or restore notes give the reader confidence that the decision was based on evidence. |
Shutdown Order Is The Design
Prioritize runtime by dependency. The modem or ONT, router, core switch, one access point, and DNS usually need far less power than storage and compute, but they keep the house reachable during a short outage. NAS and Proxmox hosts need enough runtime to stop cleanly before batteries are exhausted.
A good test is a controlled outage: pull utility power, confirm the network stays up, confirm alerts are sent, wait for the shutdown threshold, and verify the NAS or hypervisor records a clean shutdown. Then restore power and watch start order. DNS and storage should be available before app containers complain.
Real-World Example
Consider a small lab with an ONT, router, switch, access point, NAS, and Proxmox host. The network gear might draw 25W to 40W, while storage and compute can easily double that. A sensible outage plan keeps the network and DNS online first, sends an alert after utility power is lost, stops nonessential VMs early, shuts the NAS down with enough battery remaining, and leaves the router online as long as the UPS can support it.
The same numbers guide the buying decision. If the router stack draws 30W and the NAS/server stack draws 90W, putting everything on one small UPS may give neither enough runtime nor enough shutdown margin. A better layout may put the network on one UPS and the NAS or compute host on another, or it may shut compute down early while keeping internet and Wi-Fi online longer.
For cost planning, separate always-on baseline from occasional peaks. A GPU job that runs two hours a week matters less than an old switch or server idling every hour of the year. The article's recommendation is proven when measured watts, runtime, shutdown settings, and annual cost are written down.
Rollout And Recovery Plan
Roll this out by dependency order. Put the network path on protected power first, then storage, then compute. Configure alerts and shutdown thresholds before relying on runtime claims. A controlled outage during a maintenance window is the only honest way to see whether the UPS, shutdown software, and restart order behave together.
Recovery should include both directions: graceful shutdown when utility power fails and predictable restart when power returns. Document what should stay off, what should start first, and how to recover if DNS, storage, or the hypervisor returns in the wrong order.
Implementation Details
Run the controlled outage while household users know that internet and services may stop and while storage backups or heavy writes are idle. Keep a local console path, save current UPS and host settings, watch every shutdown client, and change one threshold at a time. Confirm that compute stops before storage and that the router path remains available long enough to deliver alerts and shutdown commands.
- Inventory every device that must stay up: modem or ONT, router, switch, access point, DNS, NAS, Proxmox host, and cameras.
- Estimate runtime using measured wattage, not the marketing wattage printed on power bricks.
- Install the vendor UPS agent, Network UPS Tools, Synology/QNAP integration, or Proxmox shutdown hooks.
- Set a battery threshold that leaves enough runtime for a clean shutdown.
- Document restart dependencies so DNS, storage, and identity services come up before apps that need them.
Record these details while you build, not after the memory has already gone fuzzy:
- Measured wall watts for each always-on device under normal load.
- Estimated yearly kWh and cost using the current local utility rate.
- UPS runtime, shutdown threshold, battery age, and alert delivery path.
- Restart order for router, DNS, storage, hypervisor, and dependent apps.
Evidence To Collect
Record the utility-loss timestamp, observed UPS load or wall watts, alert delivery, each shutdown trigger and completion, clean-stop logs, remaining battery indication, and the order in which DNS, storage, and applications return. These are reader-run measurements; TechGeeks did not perform them for this article. Keep annual energy calculations based on observed idle draw separate from short workload peaks.
- Measured wall watts for each always-on device, not the rating printed on the power supply.
- Annual cost math using your local kWh price and a note for UPS overhead.
- UPS runtime estimate with real load, battery age, shutdown threshold, and alert path.
- Controlled outage timeline showing when alerts fire, when compute stops, when storage shuts down, and what stays online.
- Restart-order notes showing DNS, storage, and core networking return before dependent apps.
Failure Signals
- UPS runtime is based on box marketing numbers instead of measured wall draw.
- Servers are protected but router, DNS, or switch power is not.
- A UPS has no signaling path to the NAS or hypervisor it should shut down.
- Nobody has tested what restarts first after utility power returns.
Adopt, Pilot, Defer, Avoid
- Adopt: Adopt the power plan when measured load, UPS signaling, shutdown order, and restart order have all been tested.
- Pilot: Pilot with the network stack first, then add NAS and compute shutdown once alerts and runtime are understood.
- Defer: Wait when the current setup is stable, backed up, monitored, and the proposed change is mostly curiosity.
- Avoid: Avoid buying a larger UPS before removing unnecessary always-on load or proving the shutdown workflow.
Validation Checklist
- Simulate a five-minute outage and confirm the network stays reachable.
- Simulate a low-battery shutdown during a maintenance window.
- Check that the NAS or Proxmox host records a clean shutdown, not a crash.
- Confirm alerts reach email, SMS, push, or the monitoring system.
- Record UPS battery install date and replacement window.
Common Mistakes
- Plugging laser printers or space heaters into a UPS.
- Protecting servers but leaving the router and DNS unprotected.
- Buying a UPS with no signaling path to the systems it protects.
- Never testing shutdown because the dashboard says everything is fine.
- Letting old batteries quietly turn a UPS into an expensive power strip.
Troubleshooting
| Symptom | Likely Cause | First Check |
|---|---|---|
| UPS dies too quickly | Runtime was estimated from VA rating or power-supply labels instead of measured wall draw. | Measure watts under normal load and compare against the UPS runtime chart or display. |
| NAS or server crashes | Shutdown signaling, threshold, USB/network agent, or service order is wrong. | Check UPS agent logs and run a controlled low-battery shutdown test. |
| Everything restarts badly | DNS, storage, router, and apps return in the wrong order. | Document startup dependencies and delay app services until network and storage are ready. |
Maintenance Cadence
Repeat the relevant power test after replacing a battery or UPS, moving a signaling cable, adding load, changing shutdown software, or altering the boot order. On a calendar, review self-test and battery status, continuous load, communication with each shutdown client, alert delivery, clean-stop logs, and dependency recovery. Closet temperature and battery age can change a result even when the connected equipment is unchanged.
- Monthly: Check measured load, UPS status, alert delivery, and whether any always-on device no longer earns its power budget.
- Quarterly: Run a controlled shutdown or runtime test and update the wattage and annual-cost notes with current utility pricing.
- Yearly: Replace aging UPS batteries as needed, retire high-idle hardware, and review whether scheduled workloads can stay off by default.
Power maintenance is not optional because batteries age quietly. A UPS that cannot signal shutdown or hold the measured load is just a heavy power strip.
When To Spend Money
Buy only after measuring continuous load, defining required network runtime, and mapping the signaling topology. Compare the UPS continuous watt rating, battery replacement path, communication interface, outlet arrangement, and compatibility with the NAS or hypervisor. Separate network and compute power when their runtime goals conflict; a larger VA headline cannot fix missing shutdown support or an undelivered alert.
| Stage | Signal | Practical Buying Guidance |
|---|---|---|
| Do not buy yet | The current load has not been measured and shutdown order is not written down. | Measure watts, identify critical devices, and test alerts before choosing a UPS size. |
| Small useful spend | The plan is sound but lacks measurement, signaling, or short-outage stability. | Power meter, USB-signaling UPS, network UPS cable, replacement battery, or a small UPS for router gear. |
| Larger upgrade | Runtime, clean shutdown, or always-on cost is a measured problem. | Larger UPS, separate UPS units, lower-power mini PC, efficient switch, or hardware consolidation. |
Useful Gear And Buyer Notes
The product links below are intentionally search links, starting with APC UPS USB 900VA, because model numbers, bundles, and prices change quickly. Use them to compare categories, then verify exact specifications against the article's decision points before buying. For infrastructure gear, prioritize firmware support, replaceability, warranty, idle power, and recovery behavior over headline specs.
Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.
- Amazon search: APC UPS USB 900VA
- Amazon search: CyberPower UPS USB 1500VA
- Amazon search: UPS network management card
- Amazon search: kill a watt power meter
- Amazon search: short IEC power cables
Related TechGeeks resources
- Monitoring and Health Checks for a Plex and Arr Homelab
- Linux and Homelab Notes: Start Here
- Backup and Disaster Recovery for Plex, Sonarr, Radarr, Tdarr, Prowlarr, and SABnzbd
What This Does Not Protect or Validate
UPS runtime curves, firmware, management software, replacement batteries, model bundles, and current pricing change. Verify the exact unit's continuous watt rating, communication interface, supported shutdown client, battery part, and warranty before buying. This article provides no TechGeeks runtime, battery-capacity, transfer-time, or electricity-cost measurements; its examples are inputs for a test on your actual load.
A UPS plan reduces abrupt shutdowns; it does not back up NAS data, guarantee the ISP path remains powered, secure management accounts, or cover every electrical or restart failure. A clean stop can still preserve existing corruption, and automatic boot can still leave mounts or DNS unavailable. Maintain separate backups, configuration exports, protected credentials, and a manual recovery procedure beyond the battery-backed power path.
UPS runtime estimates are not guarantees. Battery age, load, temperature, UPS model, and shutdown software all affect whether the plan works in a real outage.
Practical FAQ
What should happen to my homelab during a power outage?
A homelab should fail in a predictable order: keep the network alive first, shut down storage cleanly, stop compute before batteries are exhausted, and restart services only after power is stable. A UPS is not just backup power; it is a controlled shutdown system. The important next step is to validate the recommendation with one small test before treating it as the default.
References
- Network UPS Tools User Manual
- Proxmox High Availability
- Synology DSM UPS Support
- APC: UPS Runtime and Load Guidance
- NIST SP 800-34 Rev. 1: Contingency Planning Guide
Final Thought
The right answer is the one you can operate, document, test, and recover without guessing.
Need help applying this?
Bring TechGeeks into the real environment.
If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.
