上記のセットアップのポイントはまさにそれで、ステージングサーバーを同じバケットに向けることができると、同期を維持するのがはるかに簡単になります。
ただし、自動的にバックアップを貢献させたくない（または削除したくない）ので、これらの設定で無効にしています。
ステージングサイトのCDNを無効にする必要があることに同意します。私はまだそれをいじっていませんが、一度方法がわかったら、OPのwikiに更新/追加してください。
「いいね！」 2
ネイサン、ありがとう。S3バックアップが物事を容易にすると言及されているのを見ましたが、バックアップはサイトアセットとは異なるため、確信が持てませんでした。
すでにバックアップとメールをオフにしたので、すべて順調です。ステージングサーバーを既存のバケットに向け、CDNを使用していないことを確認します。
「いいね！」 1
バックアップの共有は、本番データベースをステージングに簡単にコピーできるため、非常に便利です。
「いいね！」 2
本番環境の Discourse を rsync メソッド を使用してミラーリングする予定です。
Discourse と連携する他のウェブサイトがいくつかあるため、開発/テスト版のサイトが開発/テスト/ステージング版の Discourse にアクセスして対話できると理想的です。
そのため、必要に応じてのみ起動し、PROD のデータベースバックアップを STAGING に定期的に復元します。毎日ではなく、月に一度程度かもしれません。
これを実行した場合、データベースの復元時に一部の設定が元に戻るのを防ぐにはどうすればよいでしょうか？ 
例えば、これらの設定は非常に役立ちます。
データベースのバックアップを復元してから、Discourse を起動する前に手動で設定を適用する方法はありますか？ 他のアイデア、提案、注意点はありますか？
S3 でバックアップを保持し、それを ENV 変数で設定している場合、バックアップを復元できる新しいサイトを簡単に起動できます。新しい VM を起動し、Discourse をクローンし、yml をコピーし、再構築して復元するだけです。投稿の引用のように、ENV 変数でデータベースの設定をオーバーライドできます。
「いいね！」 3
完璧です、簡単すぎますね 
「いいね！」 2
手順が抜けているのでしょうか？確か1年ほど前はこれでうまくいったはずなのですが。現在、項目は表示されるものの、About the Category以外のトピックや投稿が追加されません。何か変更がありましたか？
今試したところ、グループとユーザーのレコードは作成されましたが、カテゴリの作成は以下のエラーで失敗しました。
ActiveRecord::RecordInvalid: Validation failed: Category Name has already been taken (ActiveRecord::RecordInvalid)
既存の名前のカテゴリを作成しようとしないほど賢いべきだと思います。
私のサイトは空ではありませんでした。また、データベースを最初にワイプする dev:repopulate タスクもあります。
「いいね！」 1
以前使用していたこの方法でデータを投入した、私のDiscourseインスタンスの古いバックアップを復元しました。この方法を実行する必要がありましたが、うまくいきました。
データベースをドロップするには、実行しなければならないタスクがあります。db:drop rake タスクを実行すると、それが何であるかがわかります。したがって、sv stop unicorn を実行してから、データベースをドロップ、作成、移行してからタスクを実行する必要があるでしょう。あるいは、次に試すことはそれですが、あなたは別の解決策を持っています…
「いいね！」 1
14件の投稿が新しいトピックに分割されました: サーバーを2コンテナ構成に変更する
ステージングサーバーにテストデータをシードしようとしていますが、エラーが発生します。
rake aborted!
Database commands are only supported in development environment
これはマルチサイト設定なので、実行しているコマンドは次のとおりです。
./launcher enter web_only
ALLOW_DEV_POPULATE=1 bundle install
RAILS_DB=instance-x ALLOW_DEV_POPULATE=1 rake dev:populate
これまでは問題なく使用できていましたが、このエラーが発生します。データベースコマンドを本番環境で許可するように環境変数を設定できますか？