That's very true. I run quite a few services on my local network for my family (wireguard, nextcloud, homeassistant, frigate, pihole, jellyfin, bitwarden, ...).

While I enjoy setting up and playing with these service, I need to think about managing all these services as little as possible as I don't want to spend all my free time being a system admin.

Also, often a new release is not just a system admin task. Sure, it may not be _that_ hard to do a full backup, pull new docker images, spin them up and verify everything. The time sink comes from keeping track of all the releases of all the different projects, reading up about changes, how the upgrade process works, and so on.

On top of that, my family has become reliant on several of these services, especially nextcloud and bitwarden. The last thing they want are major changes to it. Long term stability with minimal changes can be a feature!

I am exactly in the same situation as you (I did not know frigate, but I do not have cameras either - otherwise you listed my main systems).

I managed to reduce administration to a minimum by using watchtower to automatically upgrade my containers and using mostly the :latest label.

This bit me only twice in a few years:

- with the 19-20 migration of Nextcloud, I had one big blank screen when logging in but the synchronization was working. Turns out it was a new default app (something about dashboarding) that was causing it. Googling an fixing took an hour.

- with one upgrade of Home Assistant where my devices were not available anymore, there was a problem with the upgrade which they fixed quickly but I have already upgraded. Reading the docs/forum and fixing took an hour.

I can live with these two hours across two or three years.

I backup /etc on my server with Borg and I know that, worst case, I will recover. I tested this DRP two weeks ago bare metal (recovering to an empty VM from scratch, that is an ubuntu ISO and ultimately getting my encrypted backups from a friend's system -> it really helped to highlight what I was missing)

I'm currently testing a new appliance setup with Nextcloud which includes the ability to use containers as a default for everything, if your container can be moved to an empty VM, nothing gets deleted as I didn't touch it. I would be really happy if this helped.

Could you please elaborate a bit on the appliance?

I use a home-grade PC with Ubuntu LTS on which there is nothing except for:

- docker

- borg (backup program)

- wireguard (VPN)

- sshd

I then copy /etc/docker from backup, mount some external disks with the data (either backed up or not for things I do not care about), reboot and I am done.

My recovery lasted one hour from starting the download of the ISO to being back on line.

I don't disagree but as a hobbyist I don't really want system administration problems. Well and I was mostly interested in Nextcloud as a possible alternative to Dropbox/Google drive with versioning and, I hoped, backups.

However the only proper backup solution that I could confidently state would allow me to recover should disaster strike was the one you just explained e.g. putting everything in docker and snapshotting the entire filesystem. At which point I'm basically running 3 virtual file systems on top of each other just to have a better UI, which seemed a bit silly.

First things first: don't get me wrong, I do understand your point.

The thing is: you have a system administration problem, whether you want or not (that is a big part of what you're actually paying for when you buy Dropbox or when you let Google feed on your data).

Now, as an hobbyist, when you start depending on services you set up and manage yourself, it would be a good idea to take some time to learn additional tools to enjoy your hobbies more.

Think about this as in "leveling up" your hobby.

---------------------------------------------------------------------

Now on a lighter tone, there are simpler ways to have a backup strategy, as long as you are okay with lower guarantees.

You might not use zfs, and use simple LVM snapshots. You might want to use no snapshotting at all and just do a nightly backup via a cronjob: at 3AM you just switch everything down (docker-compose down if you're using it), do a rsync to another host, start it back up. It's way simpler but you'd only get a yesterday's copy in case of problem.

But then again, that would safeguard you when doing upgrades: disable backup, perform upgrade, test everything, re-enable backup, resume operations. Worst case scenario you rsync back the yesterday's data and you resume normal operation.

"It's way simpler but you'd only get a yesterday's copy in case of problem."

I have a restic backup running on that plan instead of rsync, which means I get true backups. The nice thing about that it is that this can be integrated into any "docker compose" pipeline that you like. I'm generally not as hot on Docker as a lot of people but it does do a nice job of containing household services into a text file that can be easily checked into source control, and easily backed up, as long as it can be run in docker.

It's a pity that Sandstorm started before Docker was a practical option for most people. There's probably some room for a Sandstorm 2.0 that "just" uses Docker and provides some grease around setting up this stuff on a system from a top-level configuration file or something. It would go from a massive project in which you have to "port" everything to something some hobbyists could set up. It wouldn't be as integrated, but it would work.

Wasn't Sandstorm a bit incompatible with Docker? Notably it didn't just containerize apps, it communicated over a custom protocol to fully isolate and limit their permissions. Eg network/disk access was tightly controlled.

Though perhaps there was a shim layer? Eg over normal containers, it shimmed network/disk from the container over the Sandstorm RPC buffer?

Really cool tech regardless, but it had a big tech maintenance burden. That's my fear in all these self hosted apps. Everything needs to be maintained for it to feel good to the user, and that seems like such a tall ask.

The old blog post on this: https://sandstorm.io/news/2014-08-19-why-not-run-docker-apps

> I have a restic backup running on that plan instead of rsync, which means I get true backups.

yeah, yeah, absolutely. rsync is the first thing that came to my mind, but any tool that does a similar/equivalent job is fine here :)

> you have a system administration problem, whether you want or not

Right. You can pay people to do things for you, or you can do them yourself, but either way the things have to be done, and they should be done by someone who is good at it and has a contract with you -- employment or otherwise.

> should be done by someone who is good at it

I'm not 100% okay with this statement.

One has to be able to start somewhere. How do you "get good at it" ? You proceed via steps. you challenge yourself, you reach an improvement, enjoy that improvement for a while, then you challenge yourself again when you see room for improvement.

But just saying "nah let somebody else do that" is not what we want here. We're hobbyist, we want and enjoy doing stuff ourselves. Doing a sub-optimal work is okay, we will improve over time :)

sharing our experiences and procedures here is part of that

This is true to a point. But eventually, you've gotten all you can from learning and managing a new thing. You can't reasonably make it more efficient and there are no benefits to spending more time learning it. This is when it shifts from a hobbyist's exploration to a routine, mundane task that requires time and attention while offering no _new_ benefit.

For some hobbyists there's comfort in this repetition; for others, it's just a time sink with high opportunity cost.

There is a middleground, imo. The way apps are designed massively impacts the general requirements of system administration.

What we're seeing is largely centralized applications and the work it takes to manage them. Ignore UX for a second, and imagine you wrote a database on top of a distributed system - ala IPFS - and all modifications were effectively pushed into IPFS. This suddenly boils the system administration tasks down to:

1. make sure my IPFS node is up to date

2. make sure my computer is online

And even those can be heavily mitigated with peers who follow each other.

Now we're not there yet, i'm not advertising a better solution. I'm simply saying that part of the administration is a heavy lift simply because of how these apps were written. I think we can do better for the home user.

Secure Scuttlebutt is a lot easier to maintain, for example. The most important thing with that is that you simply connect to the internet and publish your posts/fetch other posts. In doing so, other people make backups for you and you of them. Backing up your key seems like the highest priority.. and even that could be eliminated i imagine, in the P2P model at least. Very low maintenance.

>You can pay people to do things for you, or you can do them yourself, but either way the things have to be done

Nah. I had an elaborate home setup for a while as a hobby and the ongoing hassles (including NextCloud upgrade complexities) just led me to turning it all off and making do with simpler or no solutions.

I’ve learned my lesson about mixing hobbyist tinkering with something your family comes to expect as an everyday convenience - that while you on a random Saturday morning might be hyped about deploying the latest self hosted cool stuff, the other you on some random Thursday at 10pm when everything malfunctions is gonna hate past-you’s guts for putting you in this position.

> You can pay people to do things for you, or you can do them yourself,

or be a parent of a geek and have it done, with 24/7/365 support and training, and remote support of some magical things like "hey! I had a button appearing and I pressed it and now I am not sure I have internet anymore". Of course said "customer" has no idea about what was on the button. Etc. etc.

I am the geek and I love my parents :)

Maybe their hobby is not tinkering with Nextcloud and they would rather put that limited time/energy into setting up k8s clusters or developing a web app. Who knows? The point is with limited time one has to pick their battles and maybe setting up zpools and a full next cloud docker compose isn't what they want to spend their time on.

Again, I see your point, because I've been there :)

But you're missing an important point of view: do you rely on that data?

If it's a toy project, don't even bother, just ignore all my replies.

If you do rely on nextcloud and the data stored there, having a backup procedure and safeguards for the upgrade process helps a lot.

Next time you perform an upgrade you can proceed without fears and stress, and way faster (if you run on docker) and that frees up time to play with kubernetes clusters and webapp development :)

Right but I think the original point was that it would be nice not to have to do that.

An LTS connected to a NAS would avoid all of that. Lol.

Except it's not your call to make, or OP's call to make.

You're already getting quite a piece of software for free, demanding extended long-term support isn't really fair, expecially if you consider that they offer a simple update procedure.

There was a wish. Not a demand.

Many software has it so it's not unreasonable to simply discuss something that would be nice

> The point is with limited time one has to pick their battles

Yeah, that's why I pay for a managed K8s instance for my toy projects but do my own sysadmin work on various self-hosted things. The former is not my hobby so I'd rather pay someone else to do it.

This is an inherent limitation of our current tech stack, and unfortunately the cheapest mitigation we have is "take full system snapshot a.k.a. do your sysadmin work". The alternative (LTS release etc) all cost much more money.

Numerous pieces of software do LTS with no additional cost or supported via other avenues.

It's literally just branching at one release and fixing bugs in that release for a few years, which also benefits upstream branches.

That way people may lose new features but gain stability.

> It's literally just branching at one release and fixing bugs in that release for a few years

This takes engineering time, i.e. money. It may also benefit upstream branches, but again porting patch between branches takes time, especially after massive refactoring happened on latest branch.

I agree that the problem of storing data securely is a problem that you have whether you want it to or not, but I was mostly lamenting that Nextcloud does preciously little to help help you to solve this problem, as it suffers from the same problem itself (possibly worse because now you've got a data durability problem with more moving parts).

> At which point I'm basically running 3 virtual file systems on top of each other just to have a better UI, which seemed a bit silly.

This sounds like a system administration problem.

Why, exactly, did you jump to docker/etc instead of what everyone (including NextCloud) recommends which is basically "keep a copy of your nextcloud folder and a dump of your database"?[0]

If you're not confident you can properly recreate your nginx config, then keep a copy of that too.

At that point you're literally like four steps to restore from a blank slate:

  pkg install nginx php74 php74-extensions mariadb105-server
  mysql -e 'CREATE DATABASE nextcloud;'
  mysql nextcloud < backup/nextcloud.sql
  rsync /path/to/backup/ /

It sounds like most of your pain comes from trying to optimize the long tail here (recovering from a backup) at the cost of normal operation.

(FWIW, my backup strategy is cron running a shell script that "rsync/mysqldump to second disk; rclone off-site". I've recovered from this successfully (from my local copy, no transfer times) in about a half hour.)

[0] https://docs.nextcloud.com/server/latest/admin_manual/mainte...

HRCloud2 has built in backup capability. https://github.com/zelon88/HRCloud2

Full disclosure, I'm the developer.

Have you thought about using something like https://www.hetzner.com/storage/storage-share

Pretty cheap, it takes away the administration burden and you are the one in control :)

Then maybe it'd be less expensive (money and time) to pay for a netxloud account ?

> You don't have a nextcloud problem, you have a system administration problem.

Those aren't mutually exclusive. Sure, better dev ops would make major upgrades safer and easier. But for a hobbyist self-hosting their own instance, a LTS release would be a godsend to save them hours of unpaid work.

An good hobbyist should challenge themselves from time to time ;)

Who said it was a challenge? When does grunt work move beyond challenge to the point of not being worth it? I got out of self hosting because my time is too valuable. It did teach me lots of new skills, so that was great! However, somebody not wanting a time sink, is not them avoiding challenge.

This is the boat I'm in. And even if you do "everything right" and have snapshots before & after every update, you still need to actually debug why the update failed in the first place. So even then, LTS releases would be a greatly appreciated feature.

Maybe they're challenging themselves on things that interest them more...and just want a functioning Nextcloud instance?

We wouldn't tell Google engineers to mess with his Google drive in prod... why should he sacrifice data availability and integrity?

> the docker-compose file along with the configuration and data are stored in nextcloud's own dataset.

What a great idea!