💾 Archived View for jacksonchen666.com › posts › 2024-12-11 › 01-03-11 › index.gmi captured on 2024-12-17 at 10:01:34. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
2024-12-11 01:03:11Z (last updated 2024-12-11 01:03:11Z)
On 2024-02-24, I did an infodump that was also trying to be a useful but kind of general guide to backing up Fediverse servers running on Linux. This knowledge is pretty much applicable to anyone who uses a computer that can store data (including phones and tablets (although not included here)).
This guide isn't fully general or applicable to all types of devices and circumstances. The infodump hasn't been turned into that, but it does have some general information and guides applicable to other operating systems or even devices.
The following follows the infodump I wrote at that time, mostly unmodified:
I'm primarily focusing on backups for linux servers running a fedi instance. however, there will also be general backup knowledge which apply to backups in general.
for macOS, use time machine. for windows, don't ask me. for linux desktop, you could probably use this guide, but I have very little experience in linux desktop backups and this guide was made for linux server backups mainly.
backups: because there isn't another way to get data back other than having another copy.
what isn't a backup:
what is a backup:
321 backups: at least 3 copies of the data on 2 different types of media (not exactly sure what that is), with at least 1 of them being off-site (far away from the server). I think you can count one of the copies as the server that is running, but I'm not sure. the numbers are also a minimum.
what to backup (in the context of a fedi instance):
what you don't have to backup (but *could* still backup anyways):
(warning: borgmatic has affiliate links in the hosting providers section, and those are not obviously declared unless you read every word)
borgmatic is a wrapper script for borgbackup (short: borg, see also its FAQ page). should be fairly easy to use compared to writing shell scripts (which is very not easy).
you should probably use borgmatic especially if you're just starting out sysadmining, or if you don't want to make shell scripts (either because you're newbie or you don't want to maintain another piece of the puzzle).
even if you choose to only use a password to encrypt the repository, each repository contains a key that you ***must*** keep a copy of. without that, you can't access the data.
preferably test restoring your backups without ever accessing the live server to make sure you can restore independently of the server.
borgbackup info about encrypted repositories
(warning: unpaid promotion)
you could setup your own backup hosting things, or you could use 3rd party services like BorgBase which I do personally use.
personally, I have both on-site and off-site backups for redundancy, and on-site backups for fasters restores if the "site" didn't get destroyed.
regularly. daily is a good goal, hourly may be ridiculous (it is ridiculous in my case because backups would be active 90% of the time).
when specifically in a day? probably when you're asleep.
so here's what you should have for working, pretty robust, and usable backups:
if you miss some part of that list, striking your stuff in just the right way could mean permanent irreversible data loss. making sure you meet those requirements means a pretty low chance of losing your data for good.
yes, that is an overwhelming amount of things to make sure it's right. try thinking about them and do them one by one, moving on to the next when you're done.
preferably, you'll never have to access the live server itself ever during the restore test. in a real situation where the server just went poof(!), you don't have the server to use, so it makes sense to simulate not having the server when doing a restore test.
also, before you boot back into the test restored system, make sure to disconnect that system from the internet, to prevent unexpected federation (which could cause problems).
I personally do a test restore, and then document how to actually restore the server based on that test restore run.
I'd suggest doing that, as not knowing what to do next in the worst case scenario can be really discouraging when restoring from backups.
that's the end of it. congrats for reading this over 5000 characters piece of what is basically an infodump of backups (lol).