Help with setting up my hard drives for my desktop PC and my server
So I have a new desktop PC and my old desktop PC that was broken for some time, now revived and I want to make it a home server and selfhost various apps.
I’m running Debian Trixie and plan to run the same (but headless) on the server.
My old PC had a 1TB SATA SSD (one of the Samsung EVO models from around 2013/2014). It’s an old drive and it’s been in use probably for 8 years in total (initially as the system disk, then for local backup). The motherboard only has 1 m2 slot with PCIe x3.
My new PC has two 2TB nvmes, the high end Samsung 9100 PRO and Samsung 990 PRO. The first disk is my system disk so it stays. But the 990 currently is almost empty and used only for a local Restic backup. I over purchased, wasn’t sure which one to keep and my return window passed so both stayed.
I also have an external 2TB SSD on USB 3.
Now I have a few scenarios in mind and I’m having trouble making a decision. I need a 3-2-1 backup solution on both machines.
I won’t have too many services and won’t have much traffic.
I can put the 1TB SATA SSD in the server, make it the system disk. Then have the 2TB USB SSD for local backup. Or backup over SFTP to my desktop’s 990. The desktop PC stays as is with two nvme disks.
I can move the 990 PRO from my desktop PC to the server and make it the system disk. I’d use the SATA SSD in one computer and the USB SSD in the other one for local backup. My server won’t utilize 990’s speed because of PCIe x3 being the ceiling.
There are various combinations and I suffer from decision paralysis.
Re the backup, I currently do hourly local backups and daily cloud backups.
I’d rather not buy another disk due to how expensive they are.
I don’t have that much data, I won’t even use 1TB. I probably have less than 250GB counting all my documents, important files, ebooks, photos.
Any hints?
BlackEco@lemmy.blackeco.com
iBlessi@lemmy.world 23 minutes ago
Before you plan around that EVO, pull its SMART data.
smartctl -a /dev/sdXand 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 checkwith–read-data-subseton 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.