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
As a general rule, you should always keep in mind that you're not really looking for a backup solution but rather a restore solution. So think about what you would like to be able to restore, and how you would accomplish that.
For my own use for example, I see very little value in backing up docker containers itself. They're supposed to be ephemeral and easily recreated with build scripts, so I don't use
docker save
or anything, I just make sure that the build code is safely tucked away in a git repository, which itself is backed up of course. In fact I have a weekly job that tears down and rebuilds all my containers, so my build code is tested and my containers are always up-to-date.The actual data is in the volumes, so it just lives on a filesystem somewhere. I make sure to have a filesystem backup of that. For data that's in use and which may give inconsistency issues, there are several solutions:
docker stop
your containers, create simple filesystem backup,docker start
your containers.pg_dump
,mongodump
,mysqldump
, ... ), and then backup the resulting dump file.As for the OS itself, I guess it depends on how much configuration and tweaking you have done to it and how easy it would be to recreate the whole thing. In case of a complete disaster, I intend to just spin up a new VM, reinstall docker, restore my volumes and then build and spin up my containers. Nevertheless, I still do a full filesystem backup of
/
and/home
as well. I don't intend to use this to recover from a complete disaster, but it can be useful to recover specific files from accidental file deletions.This one offers the most info on understanding backups!!
For my own use I am a fan of rsync. Sync my files to a backup hard drive and off site location. Just backup the compose files and directories.