I’m working on starting up my first home server which I’m trying to make relatively foolproof and easily recoverable. What is some common maintenance people do to avoid dire problems, including those that accumulate over time, and what are ways to recover a server when issues pop up?
At first, I figured I’d just use debian with some kind of snapshot system and monitor changelogs to update manually when needed, but then I started hearing that immutable distros like microOS and coreOS have some benefits in terms of long term “os drift”, security, and recovering from botched updates or conflicts? I don’t even know if I’m going to install any native packages, I’m pretty certain every service I want to run has a docker image already, so does it matter? I should also mention, I’m going to use this as a file server with snapraid, so I’m trying to figure out if there will be conflicts to look out for there or with hardware acceleration for video transcoding.
You must log in or register to comment.
The answer to your overarching question is not “common maintenance procedures”, but “change management processes”
When things change, things can break. Immutable OSes and declarative configuration notwithstanding.
OS and Configuration drift only actually matter if you’ve got a documented baseline. That’s what your declaratives can solve. However they don’t help when you’re tinkering in a home server and drifting your declaratives.
I’m pretty certain every service I want to run has a docker image already, so does it matter?
This right here is the attitude that’s going to undermine everything you’re asking. There’s nothing about containers that is inherently “safer” than running native OS packages or even building your own. Containerization is about scalability and repeatability, not availability or reliability. It’s still up to you to monitor changelogs and determine exactly what is going to break when you pull the latest docker image. That’s no different than a native package.