Selfhosted
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.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
This looks interesting, how do you handle automated backups of all the VMs/Containers? Their docs kind of seem to say "stop everything and figure it out", but with Proxmox I'm used to it handling everything automatically to my PBS server every night.
https://linuxcontainers.org/incus/docs/main/howto/instances_backup/#instances-snapshots
This describes the jist, it’s all about snapshots! Incus loves BTRFS/ZFS.
There’s no true need for stop everything as far as I can tell.
Stop everything is applicable for databases for any backup system (snapshot avoids backing up a database mid write (guaranteed failure) but the snapshot could be during a live database multi-step operation and while intact is left in a cursed state). For databases I make sure to stop and backup (SQLite losers) or backup live (Gods’ chosen Postgres) specially so no very niche database failures occur even though it was done with instant/write-safe snapshots!!
Recovery plan is restore snapshot and if 0.1% chance of database bad bc was mid big multiple step operation then I have the .gz to restore from.
That's what proxmox has too, but snapshots aren't backups and aren't being sent to a remote backup server.. You're also not supposed to keep snapshots around for very long, whereas I have backups going back several months.
Or are you sending snapshots to a remote server? I think ZFS can do that, so maybe that's an option I can look at.
https://linuxcontainers.org/incus/docs/main/howto/instances_backup/#instances-backup-export
A bit down from the snapshots section is the export section, what I do is I export to a place then back it up with Restic. I do not compress on export and instead do it myself with the —rsyncable flag added to zstd. (Flag applies to gzip too) With the rsyncable flag incremental backups work on the zip file so it’s space efficient despite being compressed. I don’t worry about collating individual zip files, instead I rely on Restic’s built-in versioning to get a specific version of the VM/container if I needed it.
Also a few of my containers I linked the real file system (big ole data drive) into the container and just snapshot the big ole data drive/send said snapshot using the BTRFS/ZFS methods cause that seemed easier, those containers are easy enough to stand up on a whim and then just need said data hooked up.
I also restic the sent snapshot since snapshots are write-static and restic can read from it at its leisure. Restic is the final backup orchestrator for all of my data. One restic call == one “restic snapshot” so I call it monolithically with one call covering several data sources.
Hope that helps!