
* add rules * join date on profiles * deprecate follow scope * deprecate identity proofs * familiar followers * use definition lists instead of tables for defining activitypub properties * reformat notifications page into markdown * fix broken links to publicKey header * Application website is now nullable * update environment variables added and removed * fix typo * fix heading level * min_id and max_id can be used at the same time (3.3) * fix typo * new tootctl options * reformat tootctl page to use definition lists for params * add rules and configuration to Instance * fix typo * refactor instance api page * 3.3.0 duration on mutes * 3.3.0 mute_expires_at * improve section headings * 3.4.0 resend email confirmation api * 3.4.0 policy on push subscriptions * 3.4.0 add details to account registration error * refactor accounts api page and start adding relrefs to entity pages * 3.4.0 accounts/lookup api * add see also to accounts methods * add more see-also links * 3.5.0 appeal mod decisions * 3.5.0 reformat reports and add category/rule_ids params * document report entity and missing responses * fix typos * fix relrefs and url schema, add aliases to old urls * add archetypes for new methods/entities * update archetypes with see-also stubs * clearer presentation of rate limits * announcements api methods * refactor apps methods * refactor bookmarks methods + some anchors * refactor conversations methods * custom_emojis methods refactor * anchors * refactor directory methods * refactor domain_blocks methods * add see also to emails methods * fix page relref shortcodes to specific methods + refactor endorsements methods * min_id max_id * refactor favourites methods * refactor featured_tags methods * refactor filters methods, make path params consistent, i18n required shortcode * follow_requests methods * lists methods * markers methods * forgot to add entity links * media methods, also fix formatting of some json errors * mutes methods, add more see-also links * oembed methods * preferences methods * proofs methods * push methods * suggestions methods * 3.5.0 add new trend types, fix formatting * refactor streaming methods * refactor oauth methods * note that streaming api casts payload to string * refactor search methods * refactor polls methods * remove unnecessary link * reformat scheduled_statuses methods * reformat timelines methods * reformat statuses methods * 3.5.0 editing statuses * consistent use of array brackets in form data parameters * update dev setup guide, add vagrant and clean up text * add admin/accounts methods * 3.6 role entity * admin/accounts methods v2 * minor fix * stub admin/reports methods * document admin reports * add 403 example to methods archetype * cleanup entities for admin reports and add new attrs * 3.6.0 domain allows methods + normalize admin entity namespace * fix search-and-replace error * add aliases for admin entities * 3.6.0 canonical email blocks entity * 3.5.0 admin/retention api * 3.5.0 add admin::ip doc * 3.5.0 admin/reports * 3.6.0 admin/domain_allows * 3.5.0 admin/dimensions * 3.6.0 permissions and roles * minor formatting fix * add anchor link to headings * checkpoint * add update commands to dev env setup guide * change mentions of v3.6 to v4.0 * tootctl now uses custom roles * fix formatting * v2 instance api * update frontmatter, add better titles to pages * minor wording change * consistency * add more aliases * add placeholders and WIP notices * explain link pagination and stub out todos * switch baseURL to https * 422 on reports with rules but category!=violation * document bug fixes * fix typo * remove duplicate API method definition * s/tootsuite/mastodon for github links * remove unnecessary escaping * s/tootsuite/mastodon in Entity archetype * add missing nullable shortcode * clarify oauth scope when requesting a user token * api/v2/media now synchronous for images * DISALLOW_UNAUTHENTICATED_API_ACCESS * add undocumented env variables * add instance domain blocks and extended description api * add SMTP_ENABLE_STARTTLS * add description to SMTP_ENABLE_STARTTLS * take suggestions from open PRs * normalize links and flavour language * Fully document streaming API based on source code * Add mention of MIME types * bump to ruby 3.0.4 * clarify how to check on async media processing * validation of replies_policy * remove TODOs on admin account action * EmailDomainBlocks * IpBlocks * Admin::DomainBlock * remove TODOs * following hashtags * followed_tags * remove reference to unused parameter * add new oauth scopes for admin blocks and allows * fix command signature for i18n-tasks normalize * reformat code structure page * document fixes for following tags (assume 4.0.3) * Add warning about pre-4.0 hardcoded roles * add note about case sensitivity * remove use of 'simply' from docs * remove reference to silencing * add reference to IDN normalization for verified links * add lang parameter
4.3 KiB
title | description | menu | ||||||
---|---|---|---|---|---|---|---|---|
Migrating to a new machine | Copying your Mastodon installation to a new server without losing anything. |
|
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
- Set up a new Mastodon server using the [Production Guide]({{< relref "install" >}}) (however, don’t run
mastodon:setup
). - Stop Mastodon on the old server (e.g.
systemctl stop 'mastodon-*.service'
). - Dump and load the Postgres database using the instructions below.
- Copy the
system/
files using the instructions below. (Note: if you’re using S3, you can skip this step.) - Copy the
.env.production
file. - Run
RAILS_ENV=production bundle exec rails assets:precompile
to compile Mastodon - Run
RAILS_ENV=production ./bin/tootctl feeds build
to rebuild the home timelines for each user. - Start Mastodon on the new server.
- Update your DNS settings to point to the new server.
- Update or copy your Nginx configuration, re-run LetsEncrypt as necessary.
- Enjoy your new server!
Detailed steps
What data needs to be migrated
At a high level, you’ll need to copy over the following:
- The
~/live/public/system
directory, which contains user-uploaded images and videos (if using S3, you don’t need this) - The Postgres database (using pg_dump)
- The
~/live/.env.production
file, which contains server config and secrets
Less crucially, you’ll 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 you’re using it)
Dump and load Postgres
Instead of running mastodon:setup
, we’re 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. It’s okay if the username is different between the two servers.)
Copy files
This will probably take some time, and you’ll 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/
You’ll 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.
You’ll 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.