Discourse をクリーンインストールし、同日の夜に取得したバックアップを復元しました（バックアップと復元は Discourse インターフェースを使用して行いました）。\n\nバックアップにはデータベースとアップロードファイルが含まれていました。\n\nクリーンインストールにより設定が変更されたため必要だったと考えられる Discourse アプリの復元と再構築を行った後、問題が発生しました。\n\nすべてのユーザーのプロフィール画像をカスタマイズしていた人のアバターが失われてしまいました。\n\nこれは画像最適化に関連していると思われます。おそらく、launcher のアプリ再構築以外に何らかの操作を行う必要があるかもしれません。\n\nしかし、見落としのあるステップが何なのか特定できていません。\n\n標準アバター（Discourse に同梱されているもの）を失った人々のスレッドは見つけましたが、私たちのケースとは異なります。アバターを変更せず画像をアップロードしていない人々は、文字のアバターが正常に表示されています。\n\n更新情報：\n\n./launcher enter app\nrake posts:rebake\n\nを実行しましたが、解決しませんでした。\n\nもしかして posts:rebake ではないのでしょうか？
@arinaf さん、
奇妙なことに、今日も同じことが私で発生しました。nginx リバースプロキシを Unix ドメインソケットに接続した環境でのことです。全体としては問題なかったのですが、カスタムアバター画像がアイコン（人物アイコン）として表示され、文字アバターはすべて正常でした。
トラブルシューティング中に、標準的な 2 コンテナ構成（nginx フロントエンドなし、Unix ソケットなし）に戻したところ、問題は消えました。
その後、再度 nginx リバースプロキシを Unix ドメインソケットに接続した構成に戻すと、問題が再発しました。
途方に暮れています… しばらく休憩します 
明らかにデータは問題ありません。nginx リバースプロキシなしでは完璧に動作するからです。これは奇妙ですね。なぜなら、nginx リバースプロキシなしでも正常に動作するからです。LOL（笑）（どちらの構成でも問題なく動作していたのに、突然奇妙なアバターの問題が発生しました…）
それはまさに私の設定です。Docker コンテナ内で Ghost ブログなどの他のソフトウェアを実行しています。
リバースプロキシとして nginx を使用しています。
明らかに、バックアップの復元は思っているほど単純ではありません。
サムネイルの保存の問題だと思い、リベイクを何度か試しましたが、効果はありませんでした。
あなたが言ったことを試して、問題がリバースプロキシにあるかどうかを確認します（なぜそれが干渉する可能性があるのかはわかりませんが、試しても失うものはありません）。
はい…問題はバックエンドデータベース、DB の復元（または rake 実行）とは関係ないと思います。
リバースプロキシをオフにして、その 2 つのコンテナをリバースプロキシなしで実行するとすぐに問題が解決します。また、すべてのケースで DB は同じであるため、DB が原因である可能性は低いでしょう。
私は今後 12 時間ネットから離れますので、後で戻って @ariznaf の環境で何が起こったかを確認します。
コンテナ外で HTTPS を使用していますか？
アバターのURLにどのようなものが使われているか、ページソースを確認しましたか？
force_https が有効になっていないようです。
今すぐはできません。最初からやり直す必要があるからです。
元サーバーの Discourse を停止してすべてのファイルをコピーしようとしましたが、それも機能しませんでした（データベースに問題がありました）。
もう一度始め、クリーンな Discourse をインストールしてから、Discourse で作成したバックアップを復元してみます。
確認いたします。ありがとうございます。
データベースの復元や、あるホストから別のホストへの移行は、予想よりも難しくなっています。
お二人とも、ありがとうございます。
リバースプロキシを使用しておらず、宛先プラットフォームが適切に代表され、正しく設定されていれば、通常は非常に簡単です。
ただし、Discourse自体や使用しているプラグイン（公式プラグインを数個、トピックリストのプレビュー、そしていくつかのコンポーネントのみを使用しています）にアップグレードが行われていた場合は別ですが、復元をシミュレートするたびに何らかの問題が発生しました。
バックアップシステムは簡単で直感的ですが、他のサーバーにすべてを移行する必要がある場合には、十分な堅牢性を持っていません。また、柔軟性も不足しています。
完了までに時間がかかりすぎます（それほど大きくないサイトであっても、完全なバックアップはわずか3GBです）。
以前のフォーラムには100GB以上のデータがありましたが、現在のシステムではそのような大規模なフォーラムのバックアップは不可能です。
さまざまなサイズ変更されたアバター画像は、元の画像のみがバックアップに含まれており、リサイズされたバージョンは含まれていません。スケジュールされたジョブが実行され、すべてのアバターのサイズ変更されたバージョンを生成するまでには、ある程度の時間がかかります。
ああ、なるほど。
ありがとうございます。
バックグラウンドで再構築されているとは知りませんでした。
つまり、待つしかないのですね。
rake posts:rebuild などのコマンドを使ってイライラしていました。
おかげで多くの手間が省けました。本当にありがとうございます。
フォーラムの /sidekiq/scheduled にアクセスし、CreateMissingAvatars ジョブの横にある「Trigger」ボタンを押すことで、処理を高速化できます。
わあ、/sidekiq の中に隠された世界がまるまる一つあるんですね
あなたが提案してくれたことを試してみています。
しかし、CreateMissingAvatars ジョブはスケジュールされ実行されますが、ほぼ即座に終了してしまいます。完了までに数ミリ秒しかかかりません。手動で実行（Trigger を使用）してみましたが、やはり OK という結果で即座に終了してしまいます。
でも、アバターは相変わらず正しく表示されていません。
現在は元の設定を使用しており、Discourse はソケットでリスニングし、nginx がリバースプロキシとして機能しています。
今度は nginx を削除して、Discourse をポート 80 と 443 で直接実行してみます。
@ariznaf さん、こんにちは
12 時間ネットから離れていた後、今朝起きて socket-only.yml 構成に戻したところ、すべて正常に戻りました。
つまり、少なくともこの広大な Discourse ユニバースのこの端では、2 つのコンテナ、unix ソケットへの nginx リバースプロキシ 環境も再び平穏です。
この異常（気づかれた時点）の約 6 時間前に nginx フロントエンド構成に切り替えていましたが、その時点ではすべて問題ありませんでした。
@riking さんからのこの有益なヒントに基づいて（いつもありがとうございます、Kane さん）
各種リサイズされたアバター画像はバックアップに含まれず、元の画像のみが含まれます。スケジュールされたジョブが実行され、すべてのアバターのリサイズバージョンが生成されるまでには時間がかかります。
私の推測では、nginx への切り替え を行った際、多くのアバター画像がすでにキャッシュされており、再生成プロセスが完了していなかったため、問題に気づかなかったのではないかということです。時間が経つにつれてこれらの画像のキャッシュが期限切れになり、異常が現れ始めたのでしょう。
そのため、12 時間ネットから離れ（socket-only.yml コンテナはバックグラウンドで非アクティブな状態で稼働中）、朝になってみると、sidekiq が一晩中魔法のように機能していました（こちらで）。@riking さん（メタのすべてのトピックで素晴らしいサポートをありがとうございます、Kane さん）
このシナリオは、@riking さんが提案したことを裏付けるように思えます。
正直に言うと、Discourse を使うほどに、ますます気に入っています。小さなトラブルや異常も非常に興味深く、2 つのコンテナ構成は本当に優れています。
現在のコンテナの状態は以下の通りです：
# ls -l containers
-rw-r--r-- 1 discourse root 1124 Apr 15 11:29 data.yml
-rw-r--r-- 1 discourse root 3939 Apr 16 07:45 socket-only.yml
-rw-r--r-- 1 discourse root 3784 Apr 16 07:28 socket.yml
-rw-r--r-- 1 discourse root 3921 Apr 15 11:50 web-only.yml
ここで気に入っているのは、例えば今回のような アバター再生成の異常 が見られた場合でも、socket-only.yml と web-only.yml の間で簡単に切り替えられることです。
今回の場合、再生成中は web-only に戻し、プロセス完了後に再度切り替えました（すべてのコンテナは引き続き稼働中）。コンテナの再構築を行う際は、これらのコンテナと設定を非常に簡単に切り替えることができます。
20 年間にわたって LAMP フォーラムを運営してきた経験から、システム管理者の観点でも Discourse にますます感銘を受けています。
余談（編集）：
もちろん、これはメタでの私のページグレードを大きく超える内容ですが、基本的な 2 つのコンテナ構成（リバースプロキシなし）をデフォルトにするべきだと考えます。設定が非常に簡単で、2 つの yml ファイルを持つことによる「ペナルティ」と思われるものよりも、はるかに多くのメリットが得られるからです。
私の側では、インターフェースから作成したバックアップのみを使用して復元を試みました。
コメントにある通り、アバター画像やその他の小さな項目が失われました。
@riking 氏から提供されたガイダンスに従ってみましたが、うまくいきませんでした。
アバター画像の再生成を強制してプロセスを実行させようと試みましたが、数ミリ秒で「OK」ステータスで終了し、アバターは生成されませんでした。
コンテンツの移行が急務だったため、旧サーバーでフォーラムを停止し、tar を使用してコンテナと共有ディレクトリ内のすべてのコンテンツをコピーしました。その後、新サーバーに Discourse をインストール（初期設定は行わず）、共有ディレクトリとコンテナディレクトリをコピーしてアプリを再構築しました。
現在、新サーバーではすべて正常に動作しています。
バックアップからの復元は、インターフェースから再インストールして復元するだけという指示から考えると単純に見えるはずですが、予想以上に問題が複雑化しています。
復元時に何が問題となっているのか、また Discourse のバージョンがバックアップ時よりも大幅に新しい場合でも、システムが正常に起動することを確認する方法について調査する必要があります。
Discourse はとても気に入っています。
従来のフォーラムから移行してきたため、目的の場所を見つけるのが難しいと感じることがあります。
クリーンなインターフェースが、そのような場合の探索を助けてくれないこともあります。
しかし、最終的に目的の場所を見つけると、そこにあるべき場所にあり、賢明な方法で機能します。
現在、問題となっているのはバックアップからの復元と、キャッシュの過剰使用による一部のケースです。
Discourse は、ウェブブラウザで最初に読み込むのに時間がかかりますが、その後は非常に高速に動作します。これは、ほとんどの処理がユーザーの端末で行われ、アバター、画像、CSS などが大量にキャッシュされているためです。
アプリは、すでにユーザーのコンピューターにある情報を再取得しないため、サーバー側の負荷が大幅に軽減されているようです（少なくとも私の経験からはそのように思われます）。
サーバー間での移行や、Discourse の完全な再インストールを行った際にも、表示を更新しても古いコンテンツが表示され続けることがあります。
ウェブブラウザの履歴をクリアするまで、その状態から抜け出すことができませんでした。その間、私はかなり混乱し、時間を浪費しました。
ところで、バックアップ時にサムネイル画像の保存を選択した場合、アバター画像も保存されるのでしょうか？
それらを保存したほうがよいとお考えですか？
当フォーラムはそれほど大きくありませんが、36,000 枚の画像を保存するにはかなり時間がかかりました。
こんにちは、@ariznaf さん、
当社の完全バックアップも同様に、完全に gzipped した状態で約 3GB です。
これまで、あなたの投稿（上記の #13）で言及された問題のいずれも経験していません。
コマンドラインから復元していますか、それとも UI からですか？
私たちはコンテナ内でコマンドラインからのみ復元を行っています。あなたも同様だと思われますか？
それは良いニュースですね。おめでとうございます。
ご関心をお寄せいただきありがとうございます。
チュートリアルの指示に従い、インターフェースを使用して操作しました。しかし、コマンドラインから（Discourse インターフェースを使用して取得した）バックアップを復元する方法がわかりません。
以下に状況を説明します。
サーバーを a.domain.com から b.domain.com へ移行する必要がありました。
Discourse フォーラムには、カスタム SSL（ドメイン全体の SSL 証明書を使用）を介した HTTPS でアクセスします。
Discourse はソケット経由でインストールされ、HOST NAME は a.domain.com に設定されていました。
Nginx をリバースプロキシとして構成し、http(80) トラフィックを https(443) に恒久的にリダイレクトするように設定しています。また、https(443) はリバースプロキシとして機能し、https トラフィックを Discourse がリッスンしているソケットへ転送します。
a.domain.com 上でインターフェースを通じて作成したバックアップ（データベースとアップロードファイルを含む、サムネイルは含まず、約 3GB）を S3 バケットに保存していました。
Nginx をインストールし、a.domain.com からの設定ファイルをコピーして、ホスト名を a.domain.com から b.domain.com に変更しました。
その後、GitHub から Discourse をクローンしてインストールしました（30 分インストールチュートリアルで推奨されている方法）。次に、Discourse setup を実行し（この時点では Nginx は停止）、HOSTNAME を b.domain.com に設定しました。
新しい b.domain.com インストールにアクセスし、管理者としてログインしました。
インターフェースを使用して、S3 バケットへのバックアップ設定を行い、管理者復元機能を有効化し、最新のバックアップを復元しました。
これにより、新しいユーザーや設定などが反映されたため、Discourse からログアウトされます。
コマンドラインに戻り、app.yml を編集して、元のサーバー（a.domain.com）からの設定をコピーし、ホスト名のみを b.domain.com に変更しました。
その後、./launcher rebuild all を実行し、完了後に Nginx を起動しました。
Discourse フォーラムにはアクセスできますが、アバターが失われており、画像サムネイルに関する他の問題も発生しています。
@ariznaf さん、こんなに詳しい情報をありがとうございます。
正直に言うと、S3 などのクラウドストレージサービスはあまり好きではありません。私たちは「S3 ユーザー」ではないので、これ以上のアイデアは却下したほうが良いと思います。
アバターが失われたと言いますが、ページソースを確認して、どこからリクエストされているか確認しましたか？
まだ S3 にありますか？
なぜサブドメインを変更する必要があったのですか？
明確に申し上げますと、物理サーバーと DNS アドレスの両方を変更されたのですか？
Rikingは、システムがミニチュア画像を再構築する必要があると言っています。しかし、その処理は完了したようです。
もう一度試してみます。現在は別の方法で解決しました。
S3ではバックアップのみを保存し、画像やアップロードファイルはローカルに保存されています。
ただし、問題を確認するために復元テストを行う必要があります。
システムが画像をどこから取得しようとしているかを確認します。
しかし、表示されたのは白いシルエットの画像でした。リンクが壊れているのではなく、サムネイルが存在しないため、システムによって置き換えられたものと思われます。