Discourse は、スケーラビリティと信頼性のためにメディアアップロードを Amazon S3 に保存する機能があります。ただし、これらのアップロードはデフォルトではバックアップに含まれません。
このガイドでは、S3 アップロードをバックアップに含めるための非表示設定を有効にする方法について説明します。Rails コンソールまたは app.yml ファイルを介して設定するオプションがあります。
Rails コンソールを介して S3 アップロードをバックアップに含めるには、次の手順に従います。
SSH で Discourse サーバーにアクセスします。
次を実行して、Discourse Docker コンテナに入ります。
cd /var/discourse
./launcher enter app
Rails コンソールを起動します。
rails c
次を実行して設定を有効にします。
SiteSetting.include_s3_uploads_in_backups = true
コンソールとコンテナを終了するには、次のように入力します。
exit
exit
この変更はすぐに有効になります。それ以上の操作は必要ありません。
env: セクションに app.yml ファイルを追加して、この変更を行うこともできます。
Discourse アプリコンテナディレクトリにアクセスします。
cd /var/discourse
containers にある app.yml ファイルを開きます。
nano containers/app.yml
env: セクションの下に次の行を追加します。
DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true
ファイルを保存してエディターを終了します。
次を実行して変更を適用します。
./launcher rebuild app
この変更を有効にするには、./launcher rebuild app コマンドを実行して設定を適用する必要があります。
「いいね！」 9
pfaffman
2023 年 8 月 25 日午前 12:57
2
コンテナを削除して再起動するだけでは十分ではありませんか？
「いいね！」 1
再起動だけで十分で、削除する必要はないと思います。後で確認します。
ちなみに、今回のテンプレートとして使用した @pfaffman の他の howto ガイド をありがとうございます。
「いいね！」 2
pfaffman
2023 年 8 月 25 日午前 1:12
4
コンテナに適用された環境変数を変更するには、破棄して再起動する必要があると思います。
もちろん、Dockerマネージャーでアップグレードを行った場合、コンテナを破棄するとそれらは失われるため、再構築が最も安全な推奨事項となります。おそらく、最も確実な方法であるため、再構築を推奨するのが最善でしょう。
「いいね！」 3
Bathinda
2024 年 8 月 16 日午後 2:15
9
バックアップにすべてのアップロードを含めるには、この設定 で十分ではないのですか？
pfaffman
2024 年 8 月 16 日午後 2:18
10
ローカルアップロードは含まれますが、バックアップに含めるためにS3にあるファイルはダウンロードされません。
「いいね！」 1
Bathinda
2024 年 8 月 16 日午後 2:24
11
わかりました。知りませんでした。
また、上記で指示されたように、web_only または Rails コンソールで設定を変更していませんが、こちら で指示された設定のみを選択しました。
しかし、10分前にバックアップを実行したところ、数千のファイルがダウンロードされたように見えました（これは私のAWS S3ストレージバケットにあるものと推測でき、「ダウンロード」という言葉自体がリモートS3バケットフォルダからダウンロードすることを意味します）。
pfaffman
2024 年 8 月 16 日午後 2:44
12
アップロード用のS3互換オブジェクトストレージプロバイダーの設定 を設定し、ローカルアップロードをS3に移動した場合、アップロードはそこにあります。S3はバックアップされていると想定されており、ダウンロードは高価で通常は不要であるため、バックアップされていません。
S3からファイルを削除する必要がある場合（たとえば、discourse.orgでホストされていて、他のホスティングに移行する場合）は、S3に保存されているファイルを含むバックアップが必要です。
S3からファイルをダウンロードする必要があるのはなぜですか？
はい、S3からファイルをダウンロードできていないようです。おそらく、一つもダウンロードできていないと思いますが、ディスク容量がいっぱいである可能性もあります（ディスクがいっぱいというエラーが出ると思いますが、そうでない可能性もありますか？）。
「いいね！」 1
Bathinda
2024 年 8 月 16 日午後 2:54
13
ありがとうございます。もう一度。
私のサイトは非常に非常に小さいので、毎月数ドルを支払い、毎月少しずつ更新していくのは、AWS S3ストレージでは現実的ではありません。アップロード（そしておそらくバックアップフォルダの場所も）をGoogle One Drive、iDrive、Hetznerなどの安価な代替プロバイダーに移行する予定です。
しかし、今ならそうするでしょう。
「いいね！」 1
Bathinda
2024 年 8 月 17 日午前 6:18
14
何年も前にメディアの「アップロード」を AWS S3 バケットに保存することを選択したとき、その当時（確信している限り）ユーザーによってアップロードされた既存のメディアもすべて S3 に移動しました。
さらに、現在 /var/discourse/shared/web_only/uploads/default/optimized/1X フォルダを確認しましたが、png ファイルは 63 個しかなく、/var/discourse/shared/web_only/uploads/default/original/1X には 3 個しかありません。（1x を除き、‘uploads または default’ フォルダに他の同様のフォルダは存在しません。
また、S3 アップロードをバックアップに含めるように、レールコンソールや Yml ファイルのオプションはまだ変更していません。それなのに、なぜこれほど多くの「メディアアップロード」を S3 からダウンロードしたと表示されるのでしょうか？スクリーンショットはこちら 。
さらに、S3 のアップロードフォルダは約 3 GB（32,000 ファイル）ですが、バックアップログでは合計の 10% 程度である約 3.2k しかダウンロードしなかったと表示されていました。
非常に混乱しています。
AWS S3 に移行した何年も前に、そのオプションがオンになっていなかったことを再確認するための、他のレールコマンドはありますか？
どのような説明でも助かります。
このガイドでは、Discourse の非表示設定を有効にして、Amazon S3 (Simple Storage Service) のアップロードをバックアップに含める方法について説明します。
