Self-hosting

3816 readers

2 users here now

Hosting your own services. Preferably at home and on low-power or shared hardware.

Also check out:

founded 3 years ago

MODERATORS

poVoq@slrpnk.net

sam_uk@slrpnk.net

Self hosting Sunday! What's up, selfhosters?s (lemmy.nocturnal.garden)

submitted 3 days ago by tofu@lemmy.nocturnal.garden to c/selfhosting@slrpnk.net

26 comments fedilink hide all child comments

What's going on on your servers? Smooth operations or putting out fires?

I got some tinkering time recently and migrated most of my Docker services to Komodo/Forgejo. Already merged some Renovate PRs to update my containers which feels really smooth.

Have to restructure some of the remaining services before migrating them and after that I want to automate config backup for my OpnSense and TrueNAS machines.

you are viewing a single comment's thread
view the rest of the comments

[–] ccryx@discuss.tchncs.de 6 points 3 days ago

I've finally pinned down my backup automaton:

All my services are in podman containers/pods managed by systemd.
All services are PartOf= a custom containers.target.
All data is stored on btrfs sub volumes
I created a systemd service that Conflicts=containers.target for creating read only snapshots of the relevant subvolumes.
That service Wants=borgmatic.service wich creates a borg backup of the snapshots on a removable drive. It also starts containers.target on success or failure since the containers are not required to be stopped anymore.
After borg backup is done, the repository gets rclone synced to an S3 compatible storage.
This happens daily, though I might put the sync to S3 on a different schedule, depending how much bandwidth subsequent syncs will consume.

What I'm not super happy about is the starting of containers.target via the systemd unit's OnSuccess= mechanism but I couldn't find an elegant way of stopping the target while the snapshots were being created and then restarting the target through the other dependency mechanisms.

I also realize it's a bit fragile, since subsequent backup steps are started even if previous steps fail. But in the worst case that should just lead to either no data being written (if the mount is missing) or backing up the same data twice (not a problem due to deduplication).