Actually plan things and research. Too many of my decisions come back to bite me because I don’t plan out stuff like networking, resources, hard drive layouts…
also documentation for sure
Buy an actual NAS instead of a rats nest of USB hub and drives. But now it works so I’m too lazy and cheap to migrate it off.
I haven’t built one myself, but you could look into TrueNas.
Would’ve used NixOS
I would’ve gone with a less powerful nas and got a separate unit for compute. I got a synology nas with a decent amount of compute so I could run all my stuff on the nas, and the proprietary locked down OS drives me a bit nuts. Causes all sorts of issues. If I had a separate compute box I could just be running some flavor of Linux, probably Ubuntu and have things behave much more nicely
Instead of a 4-bay NAS, I would have gone with a 6-bay.
You only realize just how expensive it is to expand on your space when you have to REPLACE HDDs rather than simply adding more.
This. And build my own instead of going with synology.
Removed by mod
I’ve got the argon one v2 with a m2 drive. Works well haven’t tested speeds. Not used as a nas though.
I’ve been pretty happy with my Synology NAS. Literally trouble-free, worry-free, and “just works”. My only real complaint is them getting rid of features in the Photos app, which is why I’m still on their old OS.
But I’d probably build a second NAS on the cheap, just to see how it compares :)
What OS would you go with if you had to build one?
I’m happy with synology too for the most part. But I like a bit more flexibility I’d probably build one and use truenas or unraid.
Yes, but you’ll be wishing you had 8 bays when you fill the 6 :) At some point, you have to replace disks to really increase space, don’t make your RAID volumes consist of more disks than you can reasonably afford to replace at one time. Second lesson, if you have spare drive bays, use them as part of your upgrade strategy, not as additional storage. Started this last iteration with 6x3tb drives in a raidz2 vdev, opted to add another 6x3tb vdev instead of biting the bullet and upgrading. To add more storage I need to replace 6 drives. Instead I built a second NAS to backup the primary and am pulling all 12 disks and dropping back to 6. If/when I increase storage, I’ll drop 6 new ones in and MOVE the data instead of adding capacity.
I recently did this for the second time. Started on FreeNAS, switched to TrueNAS Scale when it released and just switched to Debian. Scale was too reliant on TrueCharts which would break and require a fresh install every couple of months. I should’ve just started with Debian in the first place.
For me:
- Document things (configs, ports, etc) as I go
- Uniform folder layout for everything (my first couple of servers were a bit wild-westy)
- Choosing and utilizing some reasonable method of assigning ports to things. I do not even want to explain what I need to do when I forget what port something in this setup is using.
Not accidentally buy a server that takes 2.5 inch hard drives. Currently I’m using some of the ones it came with and 2 WD Red drives that I just have sitting on top of the server with SATA extension cables going down to the server.
I’d plan out what machines do what according to their drive sizes rather than finding out the hard way that one of them only has a few GB spare that I used as a mail server. Certainly document what I have going, if my machine Francesco explodes one day it’ll take months to remember what was actually running on it.
I’d also not risk years of data on a single SSD drive that just stopped functioning for my “NAS” (its not really a true NAS just a shitty drive with a terabyte) and have a better backup plan
I wouldn’t change anything, I like fixing things as I go. Doing things right the first time is only nice when I know exactly what I’m doing!
That being said, in my current enviroment, I made a mistake when I discovered docker compose. I saw how wonderfully simply it made deployment and helped with version control and decided to dump every single service into one singular docker-compose.yaml. I would separate services next time into at least their relevant categories for ease of making changes later.
Better yet I would automate deployment with Ansible… But that’s my next step in learning and I can fix both mistakes while I go next time!
I do the same. I use caddy reverse proxy, and find it useful to use the container name for url, and no ports exposed
What is the benefit for making changes with separate files?
If you have relevant containers (e.g. the *arr stack) then you can bring all of them up with a single docker compose command (or pull fresh versions etc.). If everything is in a single file then you have to manually pull/start/stop each container or else you have to do it to everything at once.
This. In addition, I’ve read that it’s best practice to make adding and removing services less of a pain.
You’re not messing with stacks that benefit from extended uptime just to mess around with a few new projects. Considering my wife uses networks that the homelab influences, it would be a smarter choice for me long term to change things up.
I’d use Terraform and Ansible from the start. I’m slowly migrating my current setup to these tools, but that’s obviously harder than starting from scratch. At least I did document everything in some way. That documentation plus state on the server is definitely enough to do this transition.
deleted by creator
I’d put my storage in a proper nas machine rather than having 25tb strewn across 4 boxes
I always redo it lol, which is kind of a waste but I enjoy it.
Maybe a related question is what I wish I could do if I had the time (which I will do eventually. Some I plan to do very soon):
- self host wireguard instead of using tailscale
- self host a ACME-like setup for self signed certificates for TLS and HTTPS
- self host encrypted git server for private stuff
- setup a file watcher on clients to sync my notes on-save automatically using rsync (yes I know I can use syncthing. Don’t wanna!)
self host wireguard instead of using tailscale
You cam self-host a Headscale server, which is an open-source implementation of the Tailscale server. The Tailscale client apps can connect to it.
What is the downside of using tailscale over wireguard?
I don’t think there’s any significant downsides. I suppose you are dependent on their infrastructure and uptime. If they ever go down, or for any reason stop offering their services, then you’re out of luck. But yeah that’s not significant.
The reason I want to do this is it gives me more control over the setup in case I ever wanted to customize it or the wireguard config, and also teaches me more in general, which will enable me to better debug.
I suppose you are dependent on their infrastructure and uptime
AFAIK their infra is only used for configuring the VPN. The VPN itself is a regular peer-to-peer Wireguard VPN. If their infra goes down while a VPN tunnel is connected, the tunnel should keep working. I’ve never tested that, though.
You can self-host your own Headscale server to avoid using their infra.
Wireguard is super quick and easy to setup and use, I’d highly recommend to do that now. I don’t understand the recent obsession with Tailscale apart from bypassing cgNAT
Tailscale is an abstraction layer built on top of Wireguard. It handles things like assigning IP addresses, sharing public kegs, and building a mesh network without you having to do any manual work. People like easy solutions, which is why it’s popular.
To manually build a mesh with Wireguard, every node needs to have every other node listed as a peer in their config. I’ve done this manually before, or you could automate it (eg using Ansible or a tool specifically for Wireguard meshes). With Tailscale, you just log in using one of their client apps, and everything just works automatically.
Getting a better rack. My 60cm deep rack with a bunch of rack shelves and no cable management is not very pretty and moving servers around is pretty hard.
Hardwarewise I’m mostly fine with it, although I would use a platform with IPMI instead of AM4 for my hypervisor.
