Comment

Comment on I can not over express how happy I am with having setup my NAS from scratch.

Lichtblitz@discuss.tchncs.de ⁨6⁩ ⁨days⁩ ago

That’s what containers are for. Fucking up the container won’t fuck up the host. That was the best decision in self hosting I’ve done. Even that one virtual machine feels weird and uncomfortably legacy now but it needs to interact with hardware in a certain way that just won’t fully work with docker.

source

Sort:hotnew top

sugar_in_your_tea@sh.itjust.works ⁨6⁩ ⁨days⁩ ago
That’s what I’m doing. Here’s my setup:

BTRFS RAID W/ snapshots - can always roll back

OS installed on SSD - can always reinstall without messing with the RAID

containers installed on SSD (also BTRFS W/ snapshots) and backed up to RAID; only access RAID through bind mounts (ro if possible)

It’s incredibly unlikely that I’ll mess anything up on the host, but I can always reinstall if needed.
source
greyfox@lemmy.world ⁨5⁩ ⁨days⁩ ago
If your NAS has enough resources the happy(ish) medium is to use your NAS as a hypervisor. The NAS can be on the bare hardware or its own VM, and the containers can have their own VMs as needed.

Then you don’t have to take down your NAS when you need to reboot your container’s VMs, and you get a little extra security separation between any externally facing services and any potentially sensitive data on the NAS.

Lots of performance trade offs there, but I tend to want to keep my NAS on more stable OS versions, and then the other workloads can be more bleeding edge/experimental as needed. It is a good mix if you have the resources, and having a hypervisor to test VMs is always useful.

source
lka1988@sh.itjust.works ⁨6⁩ ⁨days⁩ ago
I’ve done this before. That’s why I have a Proxmox cluster separate from my NAS now.

source