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.