Discourse フォーラムを本番環境にリリースする前に、構築・テストを行い、意図的に欠陥を発見してきました。S3 アップロードを有効にしたテストフォーラムをあるサーバーから別のサーバーに移行したところ、復元時に添付されたすべてのコンテンツの URL がフォーラムの URL に書き換えられ、S3 のものにはなりませんでした。
幸いなことにこれはテストフォーラムなので、データについてはあまり気にしていませんが、以下のことを実現したいと考えています：
A. それでもこれを修正したい。
B. 本番環境で同様のことが発生しないよう、回避策や防止策を見つけたい。
投稿だけでなく、すべての画像・メディア・コンテンツ・アバター（これはかなり深刻です）が影響を受けました。
何か良いアイデアはありますか？
復元する前に、app.yml（管理ダッシュボード経由ではなく）で移行先のサイトの S3 を設定できます。設定が完了し、正しいバケットにアクセスできることを確認したら、復元を進めてください。メディアも正しくリンクされます。
この方法で S3 を設定する手順については、こちらをご覧ください: Configure an S3 compatible object storage provider for uploads
こんにちは、クリスさん
実際にはその手順を踏んだ結果、あの状況に至ってしまいました。
元の app.yml をそのまま宛先にコピーし、その後で元からバックアップを取得しました。問題が発生したのは復元時でした。何も変更を加えていないにもかかわらず、復元した時点で URL が書き換えられてしまい、S3 アップロードも有効な状態でした。
最終的には「rebake」で解決したようです（ただし、Discourse のキャッシュが非常に厳格なため、試した多くの対策のうち、実際に何が効いたのかは正確にはわかりません）。しかし、本番環境でバックアップから復元する場合や、できるだけ問題なく移行を行う方法については、依然として答えが出ていません。
それは、Kris が提案した環境変数ではなく、サイト設定を通じて S3 を設定したように聞こえます。リストアプロセスは S3 の情報を必要とします。サイト設定だけではそれは不可能です。
必要であれば、コンソールからアップロードを含まないバックアップを作成することもできます：discourse backup --sql_only
そのようなバックアップをリストアしても、アップロード URL は書き換えられません。したがって、新しいサーバーが同じ S3 バケットにアクセスできる限り、この方法は機能します。
S3 設定は app.yml にあります。サイト設定ではありません。
追記：
説明が不足しており、詳細を隠そうとしているわけではないと気づきました。
私たちは OVH の S3 を使用しており、それは app.yml で設定されています。
アップロードを含まないテストフォーラムのバックアップを取得しましたが、その時点では S3 が有効になっていました。
その後、同じ app.yml で新しいサイトに復元したところ、問題が発生しました。明確にしておきますが、現在は解決しています。しかし、私が何度も再構築を行ったのか、それとも Discourse のキャッシュが積極的だったのかはわかりません。そのため、この作業を正しく行い、最初から完璧に済ませる方法を知る必要があります。私の懸念は、将来プロダクションインスタンスにバックアップを復元する際に同じ問題に直面した場合、ユーザーが気づく前に即座に修正方法を正確に知っておく必要があるということです。