Pleroma Backup and Restore Procedure
In previous posts, I have covered how to self-host your own Mastodon-interoperable Pleroma server and how to get access to a free ARM server with 4 CPUs and 24GB of RAM. After running my own Pleroma server for two weeks, I looked at the resource usage history: CPUs barely do any work, and memory usage is less than 1GB on average. While Pleroma can run on 1 CPU and 2GB of RAM for single-user instance, I have decided to play it safe and downsize to 2 CPUs and 8GB of RAM for now.
If you are like me and have limited system administration experience, then following official Pleroma backup/restore documentation doesn't feel straightforward. The first issue I encountered is that I didn't keep a copy of the setup_db.sql script created during the initial configuration generation. If you still have it, keep a copy under /etc/pleroma/setup_db.psql.
If you lost it, generate a dummy configuration file using the answers matching the current server. Don't worry about using the right database password, we'll fix it in a moment:
export MIX_ENV="prod" sudo -Hu pleroma pleroma_ctl instance gen --output /tmp/config.exs --output-psql /etc/pleroma/setup_db.psql
Grab the database password from
/etc/pleroma/config.exs and update `/etc/pleroma/setup_db.sql' with the right value. This is what the setup_db.sql script should look like:
CREATE USER pleroma WITH ENCRYPTED PASSWORD 'SuperSecret123!'; CREATE DATABASE pleroma OWNER pleroma; \c pleroma; --Extensions made by ecto.migrate that need superuser access CREATE EXTENSION IF NOT EXISTS citext; CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE EXTENSION IF NOT EXISTS rum;
Create a new backup Pleroma backup script (
sudo nano /etc/cron.daily/pleroma-backup) with the following contents:
#!/bin/sh systemctl stop pleroma sudo -Hu postgres pg_dump -d pleroma --format=custom -f /tmp/pleroma.pgdump mv /tmp/pleroma.pgdump /etc/pleroma/pleroma.pgdump tar -czf /tmp/pleroma-backup.tar.gz -C / /opt/pleroma /etc/pleroma /var/lib/pleroma mv /tmp/pleroma-backup.tar.gz /var/backups/pleroma-`date +%F`.tar.gz systemctl start pleroma
Make the backup script executable, then run it manually at least once:
sudo chmod +x /etc/cron.daily/pleroma-backup sudo /etc/cron.daily/pleroma-backup
This script will be run daily as a cron job, and create backup tarballs under /var/backups:
$ ls /var/backups/pleroma*.tar.gz /var/backups/pleroma-2022-12-04.tar.gz
Copy the latest backup file from the virtual machine to another location. For regular backups, use additional storage attached to the virtual machine, and ensure that if the virtual machine is lost, you can still access the backups.
Last but not least, take note of the uid of the
pleroma users on the current machine.
id -u postgres 112 id -u pleroma 113
The uid values will differ, but in order to avoid additional
chown commands when restoring the backup, it is easier to use matching uid values for the same users on the new machine.
Follow the instructions from my original Pleroma blog post and stop when you reach the configuration generation command.
At this point, you should have the
pleroma users. Use the following commands to change the uid values such that they match the previous machine:
sudo usermod -u 112 postgres sudo usermod -u 113 pleroma
Transfer the backup file to the new machine, in the same location (/var/backups). When you are ready, restore the Pleroma backup on the new machine. Beware: this operation will overwrite existing Pleroma files, so don't restore a backup unless you intend to do it.
sudo tar -xzf /var/backups/pleroma-2022-12-04.tar.gz -C /
Delete existing pleroma database and user (may not be required on a new server):
sudo -Hu postgres psql -c 'DROP DATABASE pleroma;' sudo -Hu postgres psql -c 'DROP USER pleroma;'
Run pleroma database setup script:
sudo -Hu postgres psql -f /etc/pleroma/setup_db.psql
Restore database backup (this can take a few minutes):
sudo -Hu postgres pg_restore -d pleroma -v -1 /etc/pleroma/pleroma.pgdump
Run database internal cleanup to optimize queries:
sudo -Hu postgres vacuumdb --all --analyze-in-stages
You can resume following instructions from the original Pleroma blog post, starting from the enabling and starting of the Pleroma system service:
sudo cp /opt/pleroma/installation/pleroma.service /etc/systemd/system/pleroma.service sudo systemctl enable --now pleroma.service
Make sure that the Pleroma service is running before continuing further:
$ netstat -tln | grep 4000 tcp 0 0 127.0.0.1:4000 0.0.0.0:* LISTEN
If it does, then congratulations! The trickiest part of the restore procedure has worked. You can now update DNS records to point your domain name to the public IP address of the new virtual machine and request a new certificate from letsencrypt.
Once everything is up and running, don't forget to flush the DNS cache (
ipconfig /flushdns on Windows), shut down the previous machine, and try loading Pleroma from the new machine. If it works, you can now safely delete the older virtual machine, and consider the migration a success!