A second UPS is worth buying for network gear when the router, ONT or modem, and core switch need a different runtime or physical power path from the servers. Keep one UPS when everything is co-located, the measured load fits comfortably, and the existing battery already lets servers shut down while essential networking stays available long enough for your outage plan.
Start With One UPS and a Tiered Load Plan
The default should not be two batteries. Put only essential devices on battery-backed outlets, measure actual watts, and define which equipment must remain online after a longer outage. A server may need only enough time to stop cleanly, while the router and core switch may need to stay up for alerts, cameras, remote management, or a work call.
Network equipment can be dramatically lighter than the compute tier. ServeTheHome measured a 2026 Ubiquiti UXG-Lite gateway at roughly about 2 W with network ports connected, with a sub-4 W rated maximum for that device. One gateway does not represent a whole rack, but the measurement supports the buying logic: a low-draw networking tier can have a very different runtime requirement from servers and storage.
If one existing UPS can keep the network powered through the required window after compute shuts down, a second UPS adds battery age, testing, outlets, and replacement cost without changing the outcome. Split only after the shared unit fails a named runtime, location, or failure-domain requirement.
A Second UPS Pays Off When Network Runtime Must Be Much Longer
Routers, modems or ONTs, and small switches often draw much less power than servers and disk arrays. Putting them on their own battery prevents high server load from consuming the energy that could otherwise keep basic connectivity alive. This is especially useful when the servers can shut down after a few minutes but the household wants internet, VoIP, cameras, or remote alerts through a longer local outage.
An older but directly measured Tom's Hardware test used a low-power APC unit with a modem, router, and ATA combination drawing about 14 W and estimated roughly two hours of runtime from that specific setup. The low-load network runtime is not a sizing promise for modern gear or batteries; it is useful evidence for the underlying buying logic that low-watt networking can obtain far more runtime from a small battery than a server-heavy load.
The second UPS is less compelling when the ISP's neighborhood equipment goes dark during the same outage. Keeping your router powered does not guarantee upstream Internet service. Decide whether the required outcome is local LAN availability, remote connectivity, or both.
Physical Separation Can Make a Second UPS More Practical
A modem or fiber ONT may live near the service entrance while the router, switch, NAS, and servers live in a closet or rack elsewhere. Running long extension cords or daisy-chaining power strips to force everything onto one UPS can create a worse design than using a correctly sized battery at each location.
In this case the second UPS is not a luxury redundancy purchase; it is the clean way to keep each required device on protected power where it actually sits. Map the path from provider handoff to the device that must remain reachable. Every powered hop in that path needs an outage plan.
If the network equipment is all in the same rack and there are spare battery-backed outlets with enough watt and runtime reserve, location does not justify another unit. Use the existing UPS and keep the topology simpler.
Two UPS Units Do Not Automatically Create Power Redundancy
Two batteries plugged into the same wall circuit still share the breaker, building wiring, and utility feed. They can protect different load tiers and prevent one UPS battery failure from dropping every device, but they are not equivalent to independent utility feeds or a generator-backed design.
For ordinary single-power-supply routers and switches, the main value is runtime separation and maintenance isolation. True dual-path power becomes more relevant with redundant-PSU equipment, automatic transfer switches, or genuinely separate upstream sources. Do not pay for an enterprise-style topology when the household only needs longer router runtime.
| Condition | One UPS | Second UPS |
|---|---|---|
| All gear in one rack, enough runtime | Best default | Little added value |
| Servers shut down early, network must stay online | May work with tiered shutdown | Worth it when shared battery is too short |
| ONT/modem and rack are in different locations | Awkward or impractical | Strong fit |
| High PoE load competes with server runtime | Requires load shedding | Can isolate network continuity |
| Goal is true independent power feeds | Insufficient | Still insufficient if both share one circuit |
Buy the Second UPS Only After Measuring Both Load Tiers
Measure the server/storage tier and network tier separately. Record normal watts, peak PoE draw if relevant, how long servers need to shut down, and how long the network should remain useful. Then test whether the existing UPS can meet both targets with battery-aging reserve. If it can, stop there.
The ZimaSpace guide on the first-UPS buying decision covers the more basic question of whether an always-on server needs battery protection at all. This article starts one step later: whether networking deserves its own runtime budget.
Buy a second UPS when network gear is physically separate, must remain online much longer than compute, or competes with a server load large enough to erase useful network runtime. Skip it when one correctly sized UPS already supports tiered shutdown and continuity. The extra battery should remove a specific outage constraint, not simply make the rack look more redundant.
Buying Guide
More to Read

Local AI Server Checklist Before Buying a GPU
A pre-purchase checklist for avoiding a fast but incompatible, under-cooled, or VRAM-limited GPU in a home AI server.

Container Server Storage Checklist Before One Large Pool
A storage design checklist that prevents one convenient container pool from becoming one shared capacity and recovery failure domain.

NAS Drive Mixing Checklist Before Combining Capacities
A pre-purchase and pre-deployment checklist for mixed NAS disks that prevents hidden capacity waste and unpredictable recovery behavior.

