Discourse インスタンスを別のサーバーに移動する

[Discourse]

これは、すべての設定とデータを含め、Discourse インスタンスをあるサーバーから別のサーバーに移動するためのガイドです。このガイドは、Docker を使用しているセルフホスト型 Discourse インスタンスに適用されます。

必要なユーザーレベル: システム管理者

この手順にはドメインと DNS の変更が含まれます。ソースサーバーと宛先サーバーの両方にアクセスできることを確認してください。

このガイドでは、Discourse インスタンスをあるサーバーから別のサーバーに移行するプロセスを順を追って説明し、データ、設定、構成が保持されるようにします。

@pfaffman によって追加された免責事項 2025-09-12T05:00:00Z.

これらの手順は、現在 https と Let’s Encrypt を使用しているため、正常に機能しません。新しいサーバーがキーを要求できるように、DNS がそのサーバーに向けられている必要があります。私が推奨するのは、rsync を使用して Discourse サイトを別の VPS に移動するに従うことです（おそらく --exclude postgres* を使用し、その後コマンドラインからデータベースをバックアップおよび復元します）。これは、方法を知っていれば、ローカル DNS を新しいサーバーに向けるように調整でき、インターネットの他の部分が古いサイトを見ている間にテストできるため、うまい方法です。

要約

このガイドでは、次の主要な手順を実行します。

1. 現在の Discourse インスタンス（ソースサーバー）をバックアップします。
2. バックアップファイルを宛先 Discourse インスタンス（宛先サーバー）に転送します。
3. 宛先サーバーでバックアップを復元します。
4. DNS 設定を更新します（該当する場合）。

DNS 設定の調整（必要な場合）

新しいサーバーで 同じドメイン を使用している場合は、事前に DNS エントリの TTL（生存時間）を短く設定します。これにより、更新された DNS レコードの伝播中のダウンタイムを最小限に抑えることができます。新しいドメイン を使用する場合は、この手順は省略できます。

ソースサーバーへのログインと準備

1. 管理者権限を持つアカウントで、ソースの Discourse インスタンスにログインします。
2. ソースサーバーと宛先サーバーの両方が次を使用していることを確認します。
   • 同じ Discourse バージョン。
   • 同じプラグインセット。
3. /admin/upgrade にアクセスして、両方のサーバーで Discourse バージョンをアップグレードします。

より新しいバックアップを古い Discourse バージョン、または互換性のない PostgreSQL バージョンに復元するとエラーが発生する可能性があるため、避けてください。

バックアップの作成とダウンロード

1. ソースの Discourse インスタンスで /admin/backups に移動します。
2. Backup ボタンをクリックしてバックアップを作成します。
   
   
3. プロンプトが表示されたら、Yes をクリックして確認します。
4. バックアップが完了したら、Backup files タブに移動し、新しく作成されたバックアップを見つけます。
5. Download をクリックして、ダウンロードリンクを含むメールを受け取ります。メール内のリンクをクリックして、バックアップファイルをローカルに保存します。
   
   

続行する前に、app.yml ファイルを確認し、CDN 構成、インストールされているプラグイン、HTTPS サポートなどのオプション設定がソースサーバーと宛先サーバー間で一貫していることを確認してください。

宛先サーバーでのバックアップの復元

コマンドラインからバックアップを復元するには、関連ドキュメントを参照してください。

1. 宛先の Discourse インスタンスに管理者としてサインインします。
2. /admin/backups/settings に移動し、allow restore 設定を有効にします。
3. /admin/backups に移動し、Backup files タブをクリックします。Upload ボタンをクリックして、ダウンロードしたバックアップファイルをアップロードします。
   
   
4. アップロードが完了したら、アップロードされたバックアップの横にある ⋮（その他のオプション）メニューをクリックし、Restore をクリックします。
   
   
5. プロンプトが表示されたら、Yes をクリックして確認します。
   復元プロセスが開始されます。これにはデータベースのサイズに応じて時間がかかる場合があります。プロセスが完了すると、自動的にログアウトされます。

最終処理とログイン

1. 宛先の Discourse インスタンスに管理者資格情報でログインします。
2. サイトが HTTPS を使用してバックアップされた場合、新しいサーバーで HTTPS が有効になっていることを確認します。正しく設定されていない場合は、Rails コンソールを使用して一時的に「force https」設定を無効にします。
3. app.yml ファイルを編集してインスタンスを再構築することにより、オプションの構成を再度有効にします。これには以下が含まれる場合があります。
   • CDN サポートの有効化。
   • 追加のプラグインのインストール。
   • HTTPS 構成の設定。

一般的な問題と解決策

バックアップファイルが復元されない

• ソースサーバーと宛先サーバー間で Discourse のバージョンと PostgreSQL のバージョンが一致していることを確認してください。

復元後にログインできない（HTTPS が有効な場合）

• Rails コンソールを使用して、次を実行することで force https を一時的に無効にします。

  SiteSetting.force_https = false
  

[bayardo.rivas]

このガイドは11年後の現在でも有効ですか？

DiscourseをUbuntuで実行しており、OSを20.04 LTSから24.04 LTSに、ダウンタイムを最小限にしてアップグレードしたいと考えています。AWS上にあります。

[merefield (Robert)]

@bayardo.rivas

11年経ってもまだ有効ですか？

それは少し悲観的すぎますよ

@Discourse

最終編集者 @SaraDev 2024-11-21T00:47:52Z

[Jagster (Jakke Flemming)]

それとも…現実的？つまり、このようなことのせいです。

@Discourse

ソースサーバーと宛先サーバーの間でDiscourseとPostgreSQLのバージョンが一致していることを確認してください。

[bayardo.rivas]

ドキュメントと同じように懸念して質問するのは妥当だと思います。最近、Discourseフォーラムをアップグレードしたところ、システムが壊れる問題が発生しました。最新バージョンにアップグレードしたばかりでした。新しいプラグインがDiscourseのコアシステムに組み込まれたことに関する何らかの問題です。

新しいOSを搭載した別のインスタンスに移行するのは大きな変更だと思います。このアプローチを試すのであれば、可能な限り多くのフィードバックを得たいと思います。

何か役立つコメントがあれば感謝します。ありがとうございます。

[merefield (Robert)]

このガイドは、その特定の変更の範囲外です。

[bayardo.rivas]

コメントありがとうございます。

[Gunnar (Gunnar Helliesen)]

Ubuntu 20.04 をまだ使用していますか。Docker と aufs を使用していますか？

もしそうなら、続行する前にこれを読むことをお勧めします。

Docker Upgrade Removed AUFS Storage Driver, Killed Discourse

I run a Discourse forum installation on Ubuntu 20.04.6 LTS. The Docker image uses AUFS for storage. Today, I installed upgrades via sudo apt upgrade. Now the Discourse forum is no longer accessible, and it appears to be because a Docker upgrade removed the AUFS storage driver. I see plenty of guides to configuring Docker to use Overlay2 instead, but I don’t see any guidance on how to migrate my existing Discourse installation to use Overlay2, especially now that I can’t start Docker to mount m…

[pfaffman (Jay Pfaffman)]

そうだと思いますが、よく確認しませんでした。 いいえ。DNSが新しいサイトを指していない場合、新しいサイトはLet’s Encryptからキーを取得できなくなります。そのため、バックアップを取得し、バックアップを転送し、DNSを新しいサーバーに切り替え、その後再構築する必要があります。

ダウンタイムを最小限に抑えたい場合は、Discourseサイトをrsyncで別のVPSに移動することをお勧めします。これにより、SSLキーがコピーされるため、再構築時に新しいサーバーの準備が整います。

Postgres 15にすでにアップグレードしている場合（またはそうでない場合でも）、お勧めするのは（私がやっていることですが）--exclude postgres*で再構築し、その後メインサイトをバックアップして、そのバックアップを新しいサーバーに復元することです。復元したら、DNSを切り替えます。rsyncの手順では、データベースファイルをコピーできるようにデータベースをシャットダウンします。これはあまりうまくいかない場合があるため、ほとんどの場合、データベースのみのバックアップを作成して復元します。

追記：OPに追加しました。

@Discourse

@pfaffman による免責事項追加 2025-09-12T05:00:00Z

これらの手順は、現在httpsとLet’s Encryptを使用しているため、あまりうまくいきません。これらは、新しいサーバーがキーを要求できるように、DNSが新しいサーバーを指している必要があります。お勧めするのは、Discourseサイトをrsyncで別のVPSに移動するに従うことです（おそらく--exclude postgres*を使用し、その後コマンドラインからデータベースをバックアップおよび復元します）。これは、方法を知っていれば、ローカルDNSを調整して新しいサーバーを指すようにし、インターネットの他の部分は古いサイトを見ている間に、それが機能するかどうかをテストできるため、スマートです。

[nathank (Nathan Kershaw)]

ジェイさん、ありがとうございます！以前、OPの指示に従おうとした際に、URL/DNS/LetsEncryptの件で少し行き詰まってしまった理由がわかりました。

最終的には、新しいサイトにサブドメインを使用し、新しいサーバーで復元したサイトが動作していることを確認してから、DNS/URLを素早く切り替えることで対応しました。しかし、それはかなり不安定で面倒な作業でした（特にその後のリマップのいたちごっこは！）。

なぜそのような作業が必要だったのか、今なら理解できます。そして、rsync が一部の痛みを回避できると知ってよかったです。

ここにはっきりとした指示があれば、他の人たちも助かると思います。現時点では少し混乱しており、将来的に最善の方法がわかりません。あなたの免責事項を、OP全体に書き直して（おそらく@SaraDevさんによって？）組み込むことはできないでしょうか。

[pfaffman (Jay Pfaffman)]

@nathank

OPの指示に従おうとした際に、URL/DNS/LetsEncryptの件で少し行き詰まった理由を考えていました。

だから、これらの指示に従わないことを提案したんです。

@nathank

ここで明確な指示があれば、他の人々にとって本当に役立つと思います。現状では少し混乱しています。

これらの指示を無視または削除して、私がリンクしたrsyncトピックに従うことが、人々を助けることになると思います。

何か見落としていることはありますか？

[Ethsim2 (Ethan)]

ここに遭遇したマイグレーションのエッジケースを追加しておきます。誰かの助けになれば幸いです。

スタンドアロンの Discourse インスタンスを新しい VPS に移行する際、Let’s Encrypt/SSL のエッジケースに遭遇しました。そのため、このガイドに従って作業している他の人にとって有用な場合に備えて、正確な診断と復旧手順をまとめました。

私の場合、app 内の nginx が起動しませんでした。その原因は、/var/discourse/shared/standalone/ssl/ 内の両方の .cer ファイルがゼロバイトのファイルになってしまったことです：

PEM_read_bio_X509_AUX() failed

再構築により証明書の発行が再度試みられ、何度か試行した結果、Let’s Encrypt の証明書発行レート制限に達してしまいました。古いサーバーからまだ有効な証明書ファイルをコピーするだけでは不十分でした。なぜなら、app を起動すると、それらのファイルが再びゼロバイトのファイルに置き換えられてしまうからです。

最終的に問題を解決したのは、app を停止し、古いサーバーから正常に動作している /var/discourse/shared/standalone/ssl/ ディレクトリと、対応する /var/discourse/shared/standalone/letsencrypt/ の状態の両方をコピーし、その後コンテナを再起動することでした。

完全な手順を以下に文書化しました：

server_migration_diagnosing_standard_ssl.md

これらは、この特定の移行に関する診断/復旧のメモであり、公式の移行ガイドや HTTPS ドキュメントの代わりとなるものではありません。

また、関連するゼロバイトの .cer ファイル障害モードを扱った古い Meta トピックもあります：

Let's Encrypt：空の *.cer ファイル

新しい 標準的な 30 分インストール に接続できません。AWS Lightsail、2GB メモリ、:443 を開いた Ubuntu 18.04 LTS x64 環境です。問題は、Let’s Encrypt の *.cer ファイルが空であることです。なぜでしょうか？ nginx ログ root:/var/log/nginx# ls -ltrh -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 error.letsencrypt.log -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 access.letsencrypt.log -rw-r–r-- 1 www-data www-data 1.8M Dec 6 08:19 error.log tail error.log PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUS…