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: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
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
If you're using docker (like your DBs run in docker), then I think you're overthinking it personally. Just back up the volume that the container uses, then you can just plop it back and it will carry on carefree.
I usually did a simple
tar cvf /path/to/compressed.tar.gz /my/docker/volumefor each of my volumes, then backed up the tar. Kept symlinks and everything nice and happy. If you do that for each of your volumes, and you also have your config for running your containers like a docker-compose, congrats that's all you need.I don't know who said you can't just back up the volume, to me that's kind of the point of docker. It's extreme portability.
OK, cool. That’s helpful. Thank you!
I know in general you can just grab a docker volume and then point at it with a new container later, but I was under the impression that backing up a database in particular in this way could leave you with a database in a bad state after restoring. Fingers crossed that was just bad info. 😅
In theory the database can end up in an invalid state when you leave the database container running. What I do for most containers is to temporarily stop them, backup the Docker volume and then restart the container.
Much simpler than my solution. I'll look into this. Thank you!
Seconded, and great callout @RadDevon@lemmy.zip , yes part of my script was to stop the container gracefully, tar it, start it again, and then copy the tar somewhere. it "should" be fine, in a production environment where you could have zero downtime I would take a different approach, but we're selfhosters. Just schedule it for 2am or something.
Oh, and feel free to test! Docker makes it super easy. Just extract the tar somewhere else on the drive, point your container to the new volume, see if it spins up. Then you'll know your backup strategy is working!
Is your script something you can share? I'd love to see your approach. I can definitely live with a few minutes of down time in the early morning.
That particular one is long gone I'm afraid, but it's essentially just docker compose down, tar like I did above, docker compose up -d, and then I used rclone to upload it