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年半前に実装しました。
私にできる最善のことは、期限を設定して、ワークアラウンドがまだ必要かどうかを強制的に確認することだったと思います。このような機能があると便利かもしれません。あるいは、ワークアラウンドがまだ必要かどうかを確認するためのリマインダーを設定する責任は私にあるのかもしれません。この点では、いくつかのメモを残していたことが役立ちました。