Post by @evana@hachyderm.io

2025-12-05 01:36 UTC

@matt@toot.cafe @polotek@social.polotek.net if the data matters, you probably want something backing up that database. If the data doesn't matter, then just go ahead and lose it. 😁 While backing up a database isn't hard, it's the sort of thing that's easy to screw up and annoying to check/maintain. That's a great thing to offload to a platform (either company managed or from a service). One "cheat" I will do with managed database systems is to use multiple named databases within the same instance, so they all share backups, access control, and billing unit. For a small project, that let's me amortize the effort. For a big project, it's probably a mistake, but formalizing the backup / restore to migrate to a separate database when you got that scale might be a good practice opportunity anyway.

Replies (1)

@raven667@hachyderm.io 2025-12-05 05:27

@evana@hachyderm.io @matt@toot.cafe @polotek@social.polotek.net I dunno, I feel like systems management on traditional servers is full of mature solved problems that don't involve wild dataloss. I feel like it'd be *easier* to keep and validate backups on a standalone box than trusting some cloud provider to do it correctly and not have the backups get lost in the same outage that takes out your main server (eg having your account accidentally disabled, purging your servers and backups all at once). Dumping to an external drive you drop off once a month at your mom's house or whatever is fairly easy to reason about and not subject to the whims of capricious service providers. I feel like a lot of the technology stack around containers, the deployment methodology and config automation, only make sense for large businesses which are hyper-focused on "scalability" because they are fueled by VC money and are trying to monopolize a market. If you are just building something for personal use or for a small/medium business then you don't need that kind of scalability, you need something small and manageable and sustainable which doesn't have so many moving parts that you _need_ an automation framework to handle it. `/var/lib/pgsql` with `pg_dumpall` is just fine, `rsync` with hardlinks for dedup of backups is fine, lvm snapshots if you really need point-in-time filesystem state, cron jobs or systemd services/timers are fine, even RCS for local config management is fine, although these days git is nicer, as you can see exactly which configs you've touched and have full change history for each one, you could put that in Ansible but that seems overkill if you only have one instance of your service. You can wrap it all up in very simple shitty shell scripts if you aren't trying to replicate it out to hundreds of instances. I think trying to emulate the way tech companies run services is going to lead to a world of pain for a single admin running hobby services.

Open ##2300290