@iBlessi@lemmy.world

comments

• 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.

  on UPS monitor/shutdown service in c/selfhosted@lemmy.world · 1d ago

• 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.

  on Help with setting up my hard drives for my desktop PC and my server in c/selfhosted@lemmy.world · 31 Aug 2026