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.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
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
In general you backup everything that cannot be recreated through external services. So that would be the configuration files and all volumes you added. Maybe logfiles as well.
If databases are involved they usually offer some method of dumping all data to some kind of text file. Usually relying on their binary data is not recommended.
Borg is a great tool to manage backups. It only backs up changed data and you can instruct it to only keep weekly, monthly, yearly data, so you can go back later.
Of course, just flat out backing up everything is good to be able to quickly get back to a working system without any thought. And it guarantees that you don't forget anything.
It's not so much text or binary. It's because a normal backup program that just treats a live database file as a file to back up is liable to have the DBMS software write to the database while it's being backed up, resulting in a backed-up file that's a mix of old and new versions, and may be corrupt.
Either:
possibly triggered by the backup software, if it's aware of the DBMS
that won't change during the backup
or:
In general, if this is a concern, I'd tend to favor #2 as an option, because it's an all-in-one solution that deals with all of the problems of files changing while being backed up: DBMSes are just a particularly thorny example of that.
Full disclosure: I mostly use ext4 myself, rather than btrfs. But I also don't run live DBMSes.
EDIT: Plus, #2 also provides consistency across different files on the filesystem, though that's usually less-critical. Like, you won't run into a situation where you have software on your computer update File A, then does a
sync(), then updates File B, but your backup program grabs the new version of File B but then the old version of File A. Absent help from the filesystem, your backup program won't know where write barriers spanning different files are happening.In practice, that's not usually a huge issue, since fewer software packages are gonna be impacted by this than write ordering internal to a single file, but it is permissible for a program, under Unix filesystem semantics, to expect that the write order persists there and kerplode if it doesn't...and a traditional backup won't preserve it the way that a backup with help from the filesystem can.
By everything, does this mean the docker file and its volume?
The whole drive. The docker file and volumes are the bare minimum.
Sweet ill get to it