Probably, for what you described, with one condition: no transcoding. If Jellyfin can direct play your files to that one device, the server just hands the file through, and the device's codec support is the limit, not the Pi. If files need transcoding, a Pi 4 is the wrong box for it; an Intel N100 with Quick Sync is the step up I'd look at. So check what your TV or player can play before you buy the second Pi.

HAOS doesn't really share. It's a full Linux distribution designed to be the entire OS on whatever it's installed on, and it runs its own internal containers through the Supervisor. The Supervised install, the old middle route, is no longer supported (its end of support was release 2025.12).

So on one Pi 5 you pick. Keep HAOS and live with what runs as an app there, which is what add-ons are called now. Or put a regular Linux install with Docker on it and run the official Home Assistant Container image next to the arr stack, Deluge and Jellyfin. That's the whole trade. Container has no Supervisor, no apps and no one-click updates, so anything you run as an add-on today becomes its own container, and Thread and Z-Wave, which run as apps, get no out-of-the-box support. Either way, take the full backup first, as uten151 says, and I'd do the SSD move soon: Home Assistant's own database writes can wear out an SD card.

Once the timers do what you want, pull the UPS wall plug with the real load on it and watch the whole chain run: server goes on battery, the timer starts, the Pis get their shutdown, and the timer cancels if you plug back in early. It's the only test that exercises upsmon, upssched and every client together, and it tells you how many minutes you actually have, which the charge reading on the front of the unit doesn't.

If you'd rather not pull the plug on live gear, upscmd -l <yourups> lists what your unit supports, and on units that expose it test.battery.start.deep runs a real battery test.

Before you plan around that EVO, pull its SMART data. smartctl -a /dev/sdX and look at Power_On_Hours, Wear_Leveling_Count and Total_LBAs_Written. Eight years of use as a system disk then a backup target is not automatically fatal, but it changes whether you want it holding a backup copy or just scratch.

One specific thing worth checking given the 2013/2014 date. If it is an 840 EVO rather than an 850, that model had the read-speed degradation issue where data sitting untouched for months read back very slowly. Samsung fixed it with firmware plus a periodic rewrite of static data. A backup drive is exactly the workload that triggers it, because the data is written once and then sits. Confirm the model and that it is on the last firmware, and if it is an 840 EVO, plan on rewriting the repo occasionally rather than letting it sit for a year.

On the layout itself, the thing I would hold onto is that a Restic repo on the 990 in the same desktop is not really a second copy. Same machine, same PSU, same filesystem accident, same theft. It is useful as a fast local restore point, but for 3-2-1 purposes it counts as one copy alongside the source, not two. If you move one of the NVMes into the server, you get an actual second machine holding the second copy, and Hetzner is your offsite. That gets you to 3-2-1 without buying a NAS.

The m.2 slot being limited does not matter much for that role. A backup target is bandwidth-insensitive compared to a system disk, so putting the faster drive in the slower slot costs you little in practice.

Last thing, and it is the step almost everyone skips: schedule restic check with --read-data-subset on a rotation, and do an actual test restore to a scratch directory now and then. A repo that has never been restored from is not a verified backup, it is an assumption. Cheap to test, miserable to discover at the wrong moment.