1
0
mirror of https://github.com/mastodon/documentation synced 2025-04-11 22:56:17 +02:00
documentation/content/en/admin/migrating.md
trwnh ffbe66a389
Update content for 4.0, part 2 (#1060)
* fix relrefs around trends and related entities

* revert moving caption-links to middle of page

* hide empty menu in table of contents

* clarify edit notifs are only for boosted statuses

* following/followers no longer need auth

* fix typo

* specify cooldown period for account Move

* use the correct cooldown

* add missing parameters to accounts/id/statuses

* link to account_statuses_filter.rb

* fix typo (#1072)

* fix typo (#1073)

* fix link to http sig spec (#1067)

* simply HTTP request examples in api methods docs

* add missing client_secret to oauth/token (#1062)

* Add any, all, none to hashtag timeline

* minor formatting changes

* Update signature requirements and advice

* fix public key -> private key

* clarify use of RSA with SHA256

* Add note about saving your profile after adding rel-me link

* v2 filters api

* comment out params that shouldn't be used in v2 filter api

* admin trends

* remove old todo

* canonical email blocks + scheduled statuses

* remove under-construction warnings from finished pages

* verify api method params with source code

* fix typo (#1088)

* fix broken caption-links (#1100)

* fix formatting of entities (#1094)

* Remove keybase section from user guide (#1093)

* fix typos (#1092)

* Verify limits are accurate (#1086)

* add mention of iframe limitation (#1084)

* Add CORS header to WEB_DOMAIN example (#1083)

* Fix typo (#1081)

* pin http sigs spec at draft 8

* Revert "pin http sigs spec at draft 8"

This reverts commit 9fd5f7032b69b29e77599dd62adfe8d2f5cd4f20.

* add case sensitivity warning to 4.0 roles

* Add url length note to bio (#1087)

* remove follow scope from examples (#1103)

* clarify usage of update_credentials to update profile fields

* add noindex to Account entitity

* remove required hint from technically not required property
2022-12-14 22:55:30 +01:00

4.3 KiB
Raw Blame History

title description menu
Migrating to a new machine Copying your Mastodon installation to a new server without losing anything.
docs
weight parent
90 admin

Sometimes, for various reasons, you may want to migrate your Mastodon instance from one server to another. Fortunately this is not too difficult of a process, although it may result in some downtime.

{{< hint style="info" >}} This guide was written with Ubuntu Server in mind; your mileage may vary for other setups. {{< /hint >}}

Basic steps

  1. Set up a new Mastodon server using the [Production Guide]({{< relref "install" >}}) (however, dont run mastodon:setup).
  2. Stop Mastodon on the old server (e.g. systemctl stop 'mastodon-*.service').
  3. Dump and load the Postgres database using the instructions below.
  4. Copy the system/ files using the instructions below. (Note: if youre using S3, you can skip this step.)
  5. Copy the .env.production file.
  6. Run RAILS_ENV=production bundle exec rails assets:precompile to compile Mastodon
  7. Run RAILS_ENV=production ./bin/tootctl feeds build to rebuild the home timelines for each user.
  8. Start Mastodon on the new server.
  9. Update your DNS settings to point to the new server.
  10. Update or copy your Nginx configuration, re-run LetsEncrypt as necessary.
  11. Enjoy your new server!

Detailed steps

What data needs to be migrated

At a high level, youll need to copy over the following:

  • The ~/live/public/system directory, which contains user-uploaded images and videos (if using S3, you dont need this)
  • The Postgres database (using pg_dump)
  • The ~/live/.env.production file, which contains server config and secrets

Less crucially, youll probably also want to copy the following for convenience:

  • The nginx config (under /etc/nginx/sites-available/default)
  • The systemd config files (/etc/systemd/system/mastodon-*.service), which may contain your server tweaks and customizations
  • The pgbouncer configuration under /etc/pgbouncer (if youre using it)

Dump and load Postgres

Instead of running mastodon:setup, were going to create an empty Postgres database using the template0 database (which is useful when restoring a Postgres dump, as described in the pg_dump documentation).

Run this as the mastodon user on your old system:

pg_dump -Fc mastodon_production -f backup.dump

Copy the backup.dump file over, using rsync or scp. Then on the new system, create an empty database as the mastodon user:

createdb -T template0 mastodon_production

Then import it:

pg_restore -Fc -U mastodon -n public --no-owner --role=mastodon \
  -d mastodon_production backup.dump

(Note that if the username is not mastodon on the new server, you should change the -U AND --role values above. Its okay if the username is different between the two servers.)

Copy files

This will probably take some time, and youll want to avoid re-copying unnecessarily, so using rsync is recommended. On your old machine, as the mastodon user, run:

rsync -avz ~/live/public/system/ mastodon@example.com:~/live/public/system/

Youll want to re-run this if any of the files on the old server change.

You should also copy over the .env.production file, which contains secrets.

Optionally, you may copy over the nginx, systemd, and pgbouncer config files, or rewrite them from scratch.

During migration

You can edit the ~/live/public/500.html page on the old machine if you want to show a nice error message to let existing users know that a migration is in progress.

Youll probably also want to set the DNS TTL to something small (30-60 minutes) about a day in advance, so that DNS can propagate quickly once you point it to the new IP address.

After migrating

You can check whatsmydns.net to see the progress of DNS propagation. To jumpstart the process, you can always edit your own /etc/hosts file to point to your new server so you can start playing around with it early.