Migrating from Mastodon or Glitch

⚠️	This page is a work in progress; feel free to edit, but please do not try this on production instances

Disclaimers

This procedure is based on Mastodon and Glitch-soc documentation. It has been used successfully at least twice on instance https://fedi.lewactwo.pl.

The procedure has been used to successfully migrate a YunoHost-based instance from Glitch-soc to Ecko version 2021.12.09~ynh1. However, there is no good reason why it wouldn't work in other environments with slight modifications.

YunoHost-based instance

Preparation

Before the migration make sure that you have backed up all the necessary components of your instance. In case of YunoHost powered servers, backup requires only one command:

sudo yunohost backup --apps mastodon

Or for Glitch-soc

sudo yunohost backup --apps glitchsoc

Once you secure app backup - in case of migration failure - you can proceed exporting data from your old node. For migration to work fully, you need three essential items:

• application environment config
• database contents
• site media

Be advised: This requires you to have sudo (superuser) access!
To get them, first you have to go to your app location (cd /var/www/mastodon/live/ on YunoHost). If you use Glitch, replace mastodon with glitchsoc.

Once you are there, copy the .env.production file somewhere safe - it contains lots of static configuration options, as well as your LDAP config.

Next we'll export the media files, but first we should clean them up. Because Mastodon (and many other Fediverse nodes) copies a lot of federated content locally, your media storage can grow quickly to a large size.

Of course there is no need for us to export all the external media before migration, so we will save some time and disk space by trimming it beforehand. From your app directory execute the command

RAILS_ENV=production ./bin/tootctl media remove

Once this is done you can copy your ./public/system directory, which contains all the media (now only local files uploaded directly to your instance) to some secure location; it seems logical to use the same location that you put the environment config before. rsync -avz --progress --partial works well for this purpose.

Last thing to do is to make a full backup of your postgresql database.

sudo -u postgres
pg_dump mastodon_production -U postgres -f <your_backup_location/filename.psql>

Check that the dump was created and has reasonable contenst. Use /term in less to search for strings you expect:

exit
less <your_backup_location/filename.psql>

Remove old instance

This is really simple in Yunohost, just issue command

sudo yunohost app remove -p mastodon

Of course if you use glitchsoc, adjust it accordingly.

Install Ecko

sudo yunohost app install ecko
Proceed with the installation as normal, answer the setup prompts.

Clean defaults

Stop your application systemctl stop ecko-web ecko-sidekiq ecko-streaming Remove the default ecko database
dropdb ecko_production

Import data

Import backed up files (preferably rsync -a <backed_up_system_folder> ./public Important! Remember to set new file owner afterwards, or Ecko won't work sudo chown -R ecko:www-data ./public Create new, empty DB createdb -U ecko -T template0 ecko_production Import your db backup pg_restore -Fc -U ecko -n public --role=ecko -d ecko_production <your_db_backup_file.psql>

Finalize migration

Prepare static assets env RAILS_ENV=production ./bin/rake assets:precompile Run database migrations env RAILS_ENV=production ./bin/rake db:migrate You may encounter migrate errors in this step. If so, as explained by Glitch-soc docs you need to identify faulty migration file(s), and edit them, removing everything between def_change and end lines. Restart your services systemctl start ecko-web ecko-streaming ecko-sidekiq Regenerate users' keys env RAILS_ENV=production ./bin/tootctl accounts rotate --all

Test

Visit your instance and check out if everything works as it should :) If you encounter any problems, please let us know.