As part of setting up backups for my own GoToSocial instance, I’ve contributed some additions to the GoToSocial CLI and its backup documentation. This will hopefully make setting up backups easier for others too. This post goes through the why of setting up backups for this in the first place and looks at two pending changes to GoToSocial to make backups easier.
So why backup your Fediverse instance? Because of the signing keys that are stored in your database. For each user on your instance, as well as the instance itself, a set of signing keys are generated and used to sign outgoing HTTP requests to other instances. This is known as “secure mode” or “authorized fetch”. Other instances will fetch the public key from you, validate the signature on the request and then continue processing the request. When GoToSocial receives a request, it does the same thing. Crucially, most instances will cache that key indefinitely and there is no established method for signalling a key rollover.
This means that if you lose the instance signing key you’ll never be able to federate from the same domain again. And if you lose user signing keys they’ll have to create a new account. You can create a new set of signing keys, but federation will be broken in many ways due to aforementioned caching and lack of key rolling.
Though media attached to posts can always be refetched from the original instance, you are the original instance for accounts on your instance. If you recover the database but not local media, then posts will be partially broken. There’s also other local media like avatars, header images and custom emoji that would be lost.
To keep backups small, you only want to backup local media. Remote media can be retrieved on-demand. In GoToSocial local and remote media are stored together, keyed by account ID (which is an opaque and random identifier). This means there isn’t an obvious way by only looking at local storage as to which media you should backup.
To fix this I’ve got a PR pending to add an ability to list local media. This will list all local media files, which you can then copy somewhere, feed into a backup utility etc. A second PR is also pending that reworks the documentation to point at the new command. It also includes example configuration and helper scripts to process the output into Borg patterns you can use with Borgmatic.
Though Borg can be a little overwhelming to use, Borgmatic is fairly simple. For the purpose of backing up your GoToSocial instance you don’t have to learn the ins and outs of Borg. As a backup target, you probably want to look at Borgbase. They sponsor Borgmatic’s development and have built-in features like alerting you when backups haven’t happened in a while.
With all of this, it’s hopefully become a lot easier to set up complete backups for GoToSocial. By complete I mean including database and media. As far as storage requirements go, on my single-user instance, after de-duplication and compression, it’s clocking in at 110MB.