Or “How I did a backup/restore of my Mastodon server”

In the previous post I deployed a new Mastodon server … in this post I have “moved” this instance to a new cloud hosted server, which essentially is a backup and restore process.

I have no idea how many best practices I broke, but after reading several posts that partially gave me what to do, it worked :)

Steps I took (remembering I have a simple all-in-one config)

  1. Stood up a new cloud VPS, patched it and prepared as described in the standard docs
  2. Deployed the server to fully functional as per my previous post. (I did shift the DNS record over to the new public IP of the hosted VM once it was deployed and I knew what it was)
  3. On the old server:
    • Backup the [mastondon]/public folder and all subfolders and files using the command “tar cvpzf /backup/mastodon.tgz /var/www/mastodon/public”
    • Backup the database using the command “sudo -u postgres -i pg_dump -F t mastodon > /backup/mastodon_pgsql.tar”
    • Copy the .env.production file from /var/www/mastodon
  4. Copy these file using SCP from the old server to the new server
  5. On the new server:
    • Stop the Mastodon Services using the command “systemctl stop ‘mastodon-*.service’”
    • Copy the .env.production file to replace the existing one
    • Restore the database using the command “sudo -u postgres -i pg_restore –clean –dbname=mastodon mastodon_pgsql.tar”
    • Unpack the Public folder TAR using the command “tar -xvf mastodon.tgz -C /”
    • From the /var/www/mastodon folder run the command “RAILS_ENV=production ./bin/tootctl feeds build”
  6. reboot (I guess you could just start services but this seemed prudent)

At this point the new server IS the old server and everything just worked :)

You could also rsync instead of TAR and SCP the files, and if you use a cloud storage for usr files then the /public process is not required.

So now The Intersection mastodon server is running on the cloud VPS, and I just need to configure snapshots and backups!

Have fun.