v2026.8.0-latest.1 +4 にアップデートした後、バックアップが失敗するようになりました。以下がログです： log.txt.zip (22.1 KB)
特に、以下が関連しそうなセクションです：
[2026-08-04 03:37:52] アーカイブをアップロード中...
[2026-08-04 03:37:52] EXCEPTION: uninitialized constant Aws::S3::TransferManager
[2026-08-04 03:37:52] /var/www/discourse/lib/s3_helper.rb:453:in 'S3Helper#transfer_manager'
/var/www/discourse/lib/s3_helper.rb:332:in 'S3Helper#upload_file'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:48:in 'BackupRestore::S3BackupStore#upload_file'
/var/www/discourse/lib/backup_restore/creator.rb:437:in 'BackupRestore::Creator#upload_archive'
/var/www/discourse/lib/backup_restore/creator.rb:41:in 'BackupRestore::Creator#run'
/var/www/discourse/lib/backup_restore.rb:13:in 'BackupRestore.backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in 'Jobs::CreateBackup#execute'
/var/www/discourse/app/jobs/base.rb:313:in 'block (2 levels) in Jobs::Base#perform'
この問題をどのように解決すればよいか分かりません。
v2026.9.0-latest +565 に更新しましたが、同じ問題が発生しています。
olivia
(olivia)
3
実行中の Discourse バージョンには、Aws::S3::TransferManager を提供すべき aws-sdk-s3 のバージョンが含まれています。
公式の Discourse Docker インストールを使用していますか？ 公式の Docker セットアップを使用している場合、アップグレードの一環としてコンテナが完全に再構築されましたか？
はい、公式のDiscourse Dockerインストールを使用していると思います。確実な確認方法はありますか？インストールしてからかなり時間が経っています。
更新のため、./launcher rebuild app を実行しました。これによりコンテナが完全に再構築されたはずですが、私の理解が間違っている可能性があります。
関連するかもしれない追加の詳細です：
- Ubuntu 24.04.4 LTS を実行しています
app.yml の after_code フックで、公式の docker_manager プラグインと discourse-doc-categories プラグインをインストールしています。app.yml に他のプラグインは定義されていません。- バックアップをBackblazeが提供するS3互換ストレージに保存しようとしており、以前は正常に動作していました。
Ethsim2
(Ethan )
5
この問題を絞り込むのに役立つかもしれない方法として、実行中のコンテナ内で実際に読み込まれている aws-sdk-s3 ジェムを確認することです。
Aws::S3::TransferManager を導入した Discourse の変更により、aws-sdk-s3 は 1.182.0 から 1.227.0 にバージョンアップされました：
リンク先にある Discourse のリビジョンでは、Gemfile.lock がまだ aws-sdk-s3 1.227.0 を使用しているはずです。このバージョンには Aws::S3::TransferManager が提供されています。
コンテナに入ることを試みてみてください：
cd /var/discourse
./launcher enter app
次に、コンテナ内で：
cd /var/www/discourse
bundle info aws-sdk-s3
bundle exec ruby -e '
require "aws-sdk-s3"
puts "gem: #{Gem.loaded_specs["aws-sdk-s3"]&.full_name}"
puts "path: #{Gem.loaded_specs["aws-sdk-s3"]&.full_gem_path}"
p Aws::S3.autoload?(:TransferManager)
p Aws::S3::TransferManager
'
Rails 下でアプリケーション自体を確認することも役立つかもしれません：
RAILS_ENV=production bundle exec rails runner '
puts "aws-sdk-s3: #{Gem.loaded_specs["aws-sdk-s3"]&.version}"
p Aws::S3.autoload?(:TransferManager)
p Aws::S3::TransferManager
'
その後、以下でコンテナから離れます：
logout
もしこれにより古い aws-sdk-s3 が報告されたり、TransferManager が欠落していたりする場合、それはバックアップの例外を説明し、コンテナにインストールされたジェムが現在の Discourse の Gemfile.lock と一致していないことを示唆することになります。
1.227.0 が報告され、Aws::S3::TransferManager が正常に解決される場合、問題はより不尋常なものとなり、Sidekiq バックアッププロセスと対話型環境の間に何が異なるのかを確認する必要があることがわかります。
./launcher rebuild app を使用しているとのことなので、それは標準的な discourse_docker ワークフローのように聞こえます。上記のコマンドにより、再構築されたコンテナに実際に何が配置されたかがより正確にわかります。
aws-sdk-s3の古いバージョンがインストールされているようです。
$ bundle info aws-sdk-s3
* aws-sdk-s3 (1.177.0)
Summary: AWS SDK for Ruby - Amazon S3
Homepage: https://github.com/aws/aws-sdk-ruby
Source Code: https://github.com/aws/aws-sdk-ruby/tree/version-3/gems/aws-sdk-s3
Changelog: https://github.com/aws/aws-sdk-ruby/tree/version-3/gems/aws-sdk-s3/CHANGELOG.md
Path: /var/www/discourse/vendor/bundle/ruby/3.4.0/gems/aws-sdk-s3-1.177.0
この問題について調べていたところ、以前にこのワークアラウンドを使用して、AWS SDKがBackblazeと連携できない問題を回避していたことを思い出しました。トピックの最新情報を見ると、BackblazeがAPIを更新したため、このワークアラウンドは不要になっています。
ワークアラウンドを削除した後、バックアップが成功しました！お助けいただきありがとうございます。
Ethsim2
(Ethan )
7
この件について1つ思うことがあります：このような一時的な互換性テンプレートは、Discourseの依存関係を無期限に上書きし続けるよりも、自己期限切れやガード条件のようなものを持つ方が安全かもしれません。
例えば、一時的なソースバックポートについては、本番環境でフックを使用する予定です。まずアップストリームの修正がすでに存在するかどうかをチェックし、まだ必要であればパッチを適用します。
この場合、次のような処理を行っていれば、Discourse自体が新しいSDKの機能に依存し始めた時点で、古い aws-sdk-s3 1.177.0 のピン留めが続くのを防ぐことができた可能性があります：
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- |
if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
echo "Discourse now requires Aws::S3::TransferManager; skipping obsolete Backblaze aws-sdk-s3 downgrade"
else
echo "Applying temporary Backblaze aws-sdk-s3 compatibility pin"
bundle config set frozen false
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
bundle update aws-sdk-s3
bundle add aws-sdk-core --version 3.215
fi
この特定のチェックはあくまで例示です。より一般的なバージョンチェック、またはDiscourseが想定されるSDKバージョンを超えた際に明示的に失敗させる方が、おそらくより良い解決策となるでしょう。
Discourseが期待するバージョンとgemが一致しなくなったコンテナを黙って生成するよりも、大きなエラー（loudly failing）で失敗させる方が望ましいと考えられます。
「はっきりとエラーを出す」方が望ましいことに同意するものの、以前から私は意図的に、Discourseが期待するバージョンと一致しないgemを使用していました。新しいaws-sdk-s3バージョンはBackblazeがサポートしていないヘッダーを送信するため、バックアップが正常に動作するようにしたかったからです。
ワークアラウンドが不要になった時点で私に通知するために、事前に設定できるチェック機能があったかどうかはわかりません。このワークアラウンドは、修正が利用可能になる前の2025年4月に、1年半前に実装しました。
私にできる最善のことは、期限を設定して、ワークアラウンドがまだ必要かどうかを強制的に確認することだったと思います。このような機能があると便利かもしれません。あるいは、ワークアラウンドがまだ必要かどうかを確認するためのリマインダーを設定する責任は私にあるのかもしれません。この点では、いくつかのメモを残していたことが役立ちました。
Ethsim2
(Ethan )
9
今日、私も非常に似た状況に遭遇したので、少し補足します。
app.yml に、マージされていない Discourse の PR 用の一時的なソースバックポートを設定していました。フックでは以下を使用していました：
git apply --check /tmp/patch &&
git apply /tmp/patch
その後、アップストリーム側で影響を受ける領域の一つがリファクタリングされたため、古いパッチはもうクリーンに適用できなくなりました。git apply --check はまさに私が望んでいた動作をしました。パッチは部分的に適用されず、微妙に不整合なチェックアウトを生成するのではなく、リビルドが明確に失敗しました。
ただし、重要なデメリットもありました。これが ./launcher rebuild app の実行中に起きたため、リビルド失敗により、無効なフックを削除して再度リビルドするまで app コンテナが利用不可の状態になってしまいました。
そのため、以前の提案を少し修正する必要があると思います。本番環境向けの一時ワークアラウンドやバックポートにおいて、最も安全なアプローチは、以下の組み合わせのように思えます：
- 提案にあったような、明示的なレビュー/有効期限の指定；
- 信頼できる場合に限り、セマンティックバージョニングによるガード；
- 実用的な範囲で、本番環境のリビルドを開始する前に適用可能性の事前チェックを行うこと；
- そして最終的なセーフティネットとして、
git apply の直前に git apply --check を引き続き使用すること。
私のケースでは、有効期限/レビューのリマインダーがあればワークアラウンドを再検討するよう促され、適用可能性チェックがあれば、古いパッチが新しい Discourse チェックアウトを無言で変更するのを防ぐことができました。
つまり、有効期限に関するあなたの指摘は、今では私にとってより合理的に思えます。「このワークアラウンドはまだ必要か？」に対する完全な自動テストが存在しないことが多く、特に元のワークアラウンドが意図的にインストールをアップストリームと異なる状態にしている場合です。