A year ago I built a NAS to reduce my reliance on cloud services, and set up an arr stack. I went with TrueNAS Scale, which was on Bluefin at the time. In the past 12 months, TrueNAS Scale has been through FOUR major OS versions, with a fifth already announced. At least one of those involved a release train switch so, despite diligently checking for updates in the dashboard, I was left in the dust with an obsolete OS, and didn’t find out until it was already a huge hassle to upgrade.
I’ve been really happy with the utility and benefit of having this tool, but holy smokes how is anybody supposed to keep up with all of this? This is far from my only hobby, and I simply do not have the time, patience, or interest for a constant race to keep up with vetting new release versions and fixing what breaks every 3 weeks. I have enough tinkering hobbies as it is.
On top of that, there’s the whole blow up with TrueCharts, which has also left me with an entire suite of obsolete albatrosses around my NAS that I need to deal with. Am I still waiting for them to figure out an upgrade path? I don’t even know anymore.
Sorry for the rant, but I guess what I’m looking for is: how do you keep up with the constant maintenance and updates, and where do I go from here, in February 2025, with a system running Bluefin 22.12, a 32TB ZFS pool (RAIDZ1) that has to remain intact, and a handful of TrueCharts apps that I don’t want to lose the data from (e.g. Jellyfin configs/watch history)?
OS updates I only bother with every 6-12mo, though I also use debian which doesn’t push major updates all that regularly.
As far as software goes; pretty much everything is in a docker container with watchtower automatically pulling new updates to those nightly at 4am. It sends me email notifications, so It’ll tell me if an update fails; combined with uptime-kuma notifying me if any of my services is unavailable for whatever reason.
The rest I’ll usually do with the OS updates. Just because an update was released, doesn’t mean you’ve gotta drop everything and install it right this moment.
Honestly I have an auto backup system. And then set it up to auto update periodically. Then use Debian Server as it almost never breaks as a server distro.
I use debian, so what’s to keep up with? Apt upgrade is literally everything I need. My home server doesn’t take a lot of my time except when I want to tweak something or introduce something new. I dont really follow all the trendy stuff at all and just have it do what I need.
All of my apps are in docker containers set to restart unless stopped by me.
Then I run a cron job that is scheduled at like 3 or 4am that runs docker pull on all containers and restarts them. Then it runs all system updates and restarts the server.
Every week or so I just spot check to make sure it is still working. This has been my process for like 6 months without issue.
This is a good point. Generally if can accomplish what I want with my own scripts, I will go that route. I’ll probably avoid adding additional software to the mix since what I have works fine enough.
You might want to think about running a “stable” or “LTS” OS and spin up things in Docker instead. That way you only have to do OS level updates very rarely.
Thanks for this. I’ve recently been recreating my home server on good hardware and have been thinking it’s time to jump into selfhosting more stuff. I’ve used Docker a bit, so I guess I’ll have to do it the right way. It’s always good to know what choices now will avoid future issues.
I learned this the hard way as well… I did a big OS update on mine once and it broke almost every application running on it. Docker worked perfectly still. I transferred everything I could to Docker after that.
If it works, I don’t update unless I’m bored or something. I also spread things out on multiple machines, so there’s less chance of stuff happening like you describe with the charts feature going away. My NAS is pretty much just a NAS now.
You can probably backup your configs/data, upgrade, then deploy jellyfin again, restore, and reconfigure. You should probably backup your data on your ZFS pool. But, I recently updated to the latest TrueNas Scale from ~5 year old FreeBSD version of TrueNas and the pools still worked fine (none of the “apps” or jails worked, obviously). The upgrade process even ported my service configurations over. I didn’t care about much of the data in the pools, so only backed up the most important stuff.
My upgrades usually occur because I’m setting up a new system anyway, that way my effort is building for tomorrow in addition to the upgrades, and I get testing time to ensure changeover is pretty smooth.
For one I don’t use software that updates constantly. If I had to log in to a container more than once a year to fix something, I’d figure out something else. My NAS is just harddrives on a Debian machine.
Everything I use runs either Debian or is some form of BSD
Same, but openSUSE. Tumbleweed on my desktop and laptop, Leap on my servers.
And yeah, if I need to babysit something, I’ll use an alternative. I’ll upgrade when I’m ready to, which is usually over holidays when I’m bored and looking for a project.
Use Debian LTS or Ubuntu LTS (10 years support with free Ubuntu Pro). Turn on automatic unattended updates. Upgrade OS when you’re bored one of those years.
I’ve got backups. Haven’t updated or looked at my server in months. If I’m ever compromised by missing security updates, I just load a backup and regenerate all keys.
I don’t put any critical data on public facing servers.
In the business world it’s pretty common to do staged or switchover upgrades: test new version in a lab environment, iron out the install/config details. Then upgrade a single production server and do a test with a small group of users. Or, build new servers with the new stuff, have a set of users run on it for a while, in this way you can always just move those users back to a known good server.
How do you do this at home? VMs for lots of stuff, or duplicate hardware for NAS type stuff (I’ve read of running TrueNAS in a VM).
To borrow from the preparedness community: if you have 1 you have none, if you have 2 you have 1. As an example, the business world often runs mission-critical systems in a redundant setup in regionally-different data centers, so a storm won’t take them down. The question is how to reproduce this idea in a home lab environment.
This is not practical for a home setup. Not because it would be expensive for more hardware or whatever, but because as soon as you have multiple systems doing the same thing, their state diverges and for pretty much anything that is popular for selfhosting you cannot merge them again or mirgrate users between them without loosing anything. Distributed databases alone are a huge pita, and maintaining such redundant setups would be a million times more effort than just making sure that you can easily and quickly atomically roll back failed updates
As I said “how to reproduce this in a home setup”.
I’m running multiple machines, paid little for all of them, and they all run at pretty low power. I replicate stuff on a schedule, I and have a cloud backup I verify quarterly.
If OP is thinking about how to ensure uptime (however they define it) and prevent downtime due to upgrades, then looking at how Enterprise does things (the people who use research into this very subject performed by universities and organizations like Microsoft and Google), would be useful.
Nowhere did I tell OP to do things this way, and I’d thank you to not make strawmen of my words.
I have everything containerized (Podman) on my Debian PC and use Diun to check for updates and send notifications to a Discord server that I monitor. I do all of my updates manually so I don’t update unless I have time to troubleshoot; if it breaks I still have the configs and data so I can delete the container and start over.
I also do monthly backups to cold storage (yeah, they should be weekly/biweekly but it’s just personal data that I’m okay with losing). I don’t use a RAID config or BTFS/ZFS like some do, so it’s pretty easy to just set it and forget it. It really depends on what you’re trying to do, how bulletproof it needs to be, and how you like to organize things.
I have rss feeds for my main service updates so I know what new features I have, the services mostly run in podman containers and update automatically each Monday. I also have daily backups (timed to run just before the update on monday) in case anything does break.
If it breaks I fix it depending on how much I want/need it, mostly it’s a matter of half an hour to fix it and with my current NixOS/Podman system I haven’t yet needed to fix anything this year so it breaks infrequently.
Also why are you using Kubernetes on a single host if you want minimal maintenance? XD
My recommendation is to switch to just managing containers, you should just be able to export the volumes out of kubernetes and import them as normal volumes, as long as they’re mounted in the right place you keep your data and if it doesn’t work just try again. Not like you need to destroy the current system to slowly replace it.
Edit: I also recommend to update and reboot frequently, this stops updates and unstable configurations from piling up.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
OS updates I only bother with every 6-12mo, though I also use debian which doesn’t push major updates all that regularly.
As far as software goes; pretty much everything is in a docker container with watchtower automatically pulling new updates to those nightly at 4am. It sends me email notifications, so It’ll tell me if an update fails; combined with uptime-kuma notifying me if any of my services is unavailable for whatever reason.
The rest I’ll usually do with the OS updates. Just because an update was released, doesn’t mean you’ve gotta drop everything and install it right this moment.
First off, backups of the configs any user data that you can’t torrent should the inevitable happen.
Then set time aside to do updates, I spend Wednesday evenings updating and improving my setup.
Then find a way to track update announcements, I use both an RSS reader and newrealeases.io to know when something I run gets an update
I dont :) Mostly.
Honestly I have an auto backup system. And then set it up to auto update periodically. Then use Debian Server as it almost never breaks as a server distro.
I use debian, so what’s to keep up with? Apt upgrade is literally everything I need. My home server doesn’t take a lot of my time except when I want to tweak something or introduce something new. I dont really follow all the trendy stuff at all and just have it do what I need.
I run a Fedora server.
All of my apps are in docker containers set to restart unless stopped by me.
Then I run a cron job that is scheduled at like 3 or 4am that runs docker pull on all containers and restarts them. Then it runs all system updates and restarts the server.
Every week or so I just spot check to make sure it is still working. This has been my process for like 6 months without issue.
Try watchtower instead of cron jobs
Depends on your stance on risk since WatchTower has to run as privileged
This is a good point. Generally if can accomplish what I want with my own scripts, I will go that route. I’ll probably avoid adding additional software to the mix since what I have works fine enough.
I’ll check it out! Thanks!
You might want to think about running a “stable” or “LTS” OS and spin up things in Docker instead. That way you only have to do OS level updates very rarely.
Thanks for this. I’ve recently been recreating my home server on good hardware and have been thinking it’s time to jump into selfhosting more stuff. I’ve used Docker a bit, so I guess I’ll have to do it the right way. It’s always good to know what choices now will avoid future issues.
I learned this the hard way as well… I did a big OS update on mine once and it broke almost every application running on it. Docker worked perfectly still. I transferred everything I could to Docker after that.
If it works, I don’t update unless I’m bored or something. I also spread things out on multiple machines, so there’s less chance of stuff happening like you describe with the charts feature going away. My NAS is pretty much just a NAS now.
You can probably backup your configs/data, upgrade, then deploy jellyfin again, restore, and reconfigure. You should probably backup your data on your ZFS pool. But, I recently updated to the latest TrueNas Scale from ~5 year old FreeBSD version of TrueNas and the pools still worked fine (none of the “apps” or jails worked, obviously). The upgrade process even ported my service configurations over. I didn’t care about much of the data in the pools, so only backed up the most important stuff.
Hahahaha, one of my kind!
My upgrades usually occur because I’m setting up a new system anyway, that way my effort is building for tomorrow in addition to the upgrades, and I get testing time to ensure changeover is pretty smooth.
For one I don’t use software that updates constantly. If I had to log in to a container more than once a year to fix something, I’d figure out something else. My NAS is just harddrives on a Debian machine.
Everything I use runs either Debian or is some form of BSD
Same, but openSUSE. Tumbleweed on my desktop and laptop, Leap on my servers.
And yeah, if I need to babysit something, I’ll use an alternative. I’ll upgrade when I’m ready to, which is usually over holidays when I’m bored and looking for a project.
In life? Amphetamines.
Use Debian LTS or Ubuntu LTS (10 years support with free Ubuntu Pro). Turn on automatic unattended updates. Upgrade OS when you’re bored one of those years.
Keywords:
I’ve got backups. Haven’t updated or looked at my server in months. If I’m ever compromised by missing security updates, I just load a backup and regenerate all keys.
I don’t put any critical data on public facing servers.
In the business world it’s pretty common to do staged or switchover upgrades: test new version in a lab environment, iron out the install/config details. Then upgrade a single production server and do a test with a small group of users. Or, build new servers with the new stuff, have a set of users run on it for a while, in this way you can always just move those users back to a known good server.
How do you do this at home? VMs for lots of stuff, or duplicate hardware for NAS type stuff (I’ve read of running TrueNAS in a VM).
To borrow from the preparedness community: if you have 1 you have none, if you have 2 you have 1. As an example, the business world often runs mission-critical systems in a redundant setup in regionally-different data centers, so a storm won’t take them down. The question is how to reproduce this idea in a home lab environment.
This is not practical for a home setup. Not because it would be expensive for more hardware or whatever, but because as soon as you have multiple systems doing the same thing, their state diverges and for pretty much anything that is popular for selfhosting you cannot merge them again or mirgrate users between them without loosing anything. Distributed databases alone are a huge pita, and maintaining such redundant setups would be a million times more effort than just making sure that you can easily and quickly atomically roll back failed updates
As I said “how to reproduce this in a home setup”.
I’m running multiple machines, paid little for all of them, and they all run at pretty low power. I replicate stuff on a schedule, I and have a cloud backup I verify quarterly.
If OP is thinking about how to ensure uptime (however they define it) and prevent downtime due to upgrades, then looking at how Enterprise does things (the people who use research into this very subject performed by universities and organizations like Microsoft and Google), would be useful.
Nowhere did I tell OP to do things this way, and I’d thank you to not make strawmen of my words.
I have everything containerized (Podman) on my Debian PC and use Diun to check for updates and send notifications to a Discord server that I monitor. I do all of my updates manually so I don’t update unless I have time to troubleshoot; if it breaks I still have the configs and data so I can delete the container and start over.
I also do monthly backups to cold storage (yeah, they should be weekly/biweekly but it’s just personal data that I’m okay with losing). I don’t use a RAID config or BTFS/ZFS like some do, so it’s pretty easy to just set it and forget it. It really depends on what you’re trying to do, how bulletproof it needs to be, and how you like to organize things.
I have rss feeds for my main service updates so I know what new features I have, the services mostly run in podman containers and update automatically each Monday. I also have daily backups (timed to run just before the update on monday) in case anything does break.
If it breaks I fix it depending on how much I want/need it, mostly it’s a matter of half an hour to fix it and with my current NixOS/Podman system I haven’t yet needed to fix anything this year so it breaks infrequently.
Also why are you using Kubernetes on a single host if you want minimal maintenance? XD
My recommendation is to switch to just managing containers, you should just be able to export the volumes out of kubernetes and import them as normal volumes, as long as they’re mounted in the right place you keep your data and if it doesn’t work just try again. Not like you need to destroy the current system to slowly replace it.
Edit: I also recommend to update and reboot frequently, this stops updates and unstable configurations from piling up.
Wow, neat approach.
Ansible.
How does that help here?
For automating maintenance and updates? How exactly does it not?
They are complaining because of the number of updates and breaking changes. Ansible just a tool for bulk changes