このような問題の根本原因を特定する際にサポートが必要な場合は、お気軽にお知らせください。喜んでお手伝いいたします。
2.2GB のバックアップを復元しようとしたところ、以下のエラーが発生して復元が失敗しました：
例外：44 件の投稿が新しい S3 アップロード URL に再マッピングされません。データベース ‘default’ の S3 移行に失敗しました。
バージョンは 2.6b6 で、比較的最近のものですが、サイト自体は 2016 年製の古いものです。
時折、自動再マッピングや S3 への移行が様々な理由で失敗するバックアップに遭遇することがあります。
これは古いトピックですが、修正措置に関するお勧めはありますか？実際に復元できないバックアップを持っているのは少し不安です。
編集：このスレッドは同じ問題のようですので、間違っているかもしれないと気づきました。
さて、これまでに見た中で最も奇妙なケースです。この投稿に出くわしました。
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
すでに何時間も無駄にした後、試しに DISCOURSE_CDN_URL を定義しました。私のサイトではこの機能は使用していませんが、バックアップは正常に復元されました。
このシナリオにおいて、このパラメータの重要性は何でしょうか？@Falco @pfaffman
編集:
考え直しました。テストで成功した後、本番環境から新しいバックアップを取得し、再び新しいサーバーへの移行を開始しました。今度は失敗しましたが、エラーメッセージが変化しました。
例外：rake posts:missing_uploads が 3 つの問題を検出しました。データベース「default」の S3 移行に失敗しました。
編集2:
そこでデータベースを掘り下げて、これら 3 つの投稿を見つけました。
- 2 つは非常に古い画像で、最初に公開された後、モデレーターが修正版に置き換えたものです。これらは 2016 年と 2018 年のものです。
- しかし、最後の 1 つは奇妙でした。数週間前に私が投稿した非常に最近の投稿で、存在しなくなった開発サーバーへの onebox 化された https リンクが含まれていました。つまり、壊れたリンクが復元プロセスを妨害していました。
これら 3 つの投稿を手動で削除しました。
これで、再びテスト実行を行ったところ、バックアップが実際に成功する可能性があります。結果を待ちましょう。
@ljpp 私も同様の状況にあり、復元が失敗しています。
例外：1 つの投稿が新しい S3 アップロード URL へ再マッピングされません。データベース ‘default’ の S3 移行に失敗しました。
問題のある投稿をどのように特定し、削除したのか詳しく教えていただけますか？使用されたコマンドは何ですか？
該当の投稿は削除されました。
しかし、インストールをクリーンアップされたので、それはできないですよね？
データベースのリストアでこの問題が発生しています。問題のある投稿をどのように見つけましたか？
チェックを行うコードはここにあると思います。
したがって、これは次のとおりだと思います。
prefix = @migrate_to_multisite ? "uploads/#{@current_db}/original/" : "original/"
base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
bad = Upload.by_users.where("url NOT LIKE '#{base_url}%'")
念のため
good = Upload.by_users.where("url LIKE '#{base_url}%'")
これが機能するかどうか教えていただければ、トピックを作成することを検討します。
discourse(prod)> prefix = @migrate_to_multisite ? “uploads/#{RailsMultisite::ConnectionManagement.current_db}/original/” : “original/”
discourse(prod)> base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
discourse(prod)> bad_uploads = Upload.by_users.where(“url NOT LIKE ‘#{base_url}%’”)
discourse(prod)> bad_uploads.count
=> 0
このチェックでは0件のエラーが検出されました
オリジナルのサーバーでそれを実行しましたか？それとも、データベースが復元された後に、そのチェックを行う前に、--pause スイッチを使用して実行する必要がありますか？
古いサーバーでは実行しました。
リストアしても同じエラーが発生しました。
[2026-01-16 13:45:52] EXCEPTION: 3件の投稿が新しいS3アップロードURLにリマップされていません。db ‘default’ のS3移行に失敗しました。
[2026-01-16 13:45:52] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log’
さて、困りましたね。他に何を言えばいいのか分かりません。
good はあなたのアップロードを見つけましたか？
おそらく、私は単に --pause スイッチを使用して、そのチェックを行う前にリストアを停止するでしょう。
私はリチャードが言ったことをするでしょう。
あなたの正確な状況は分かりませんが、S3へのアップロードをオフにして、バックアップを取り、リストアしてから再度オンにするだけで済むかもしれません。これは私を何度も救ってくれました。
つまり、これらのオプションをオフにする必要があるのですね？
正解です。
- 「s3アップロードを有効にする」のチェックを外す
- バックアップ/ダウンロード
- アップロード/復元
- 「s3アップロードを有効にする」にチェックを入れる
食べ物のこと以外でイタリア語は話せません… 皆のためにGoogle翻訳にコピー＆ペーストしてくれませんか 
申し訳ありません
S3アップロードを有効にする
アップロードをAmazon S3ディスクスペースに保存します。重要：有効なS3認証情報（アクセスキーIDとシークレットアクセスキーの両方）を提供する必要があります。
S3アップロードはグローバルで既に有効になっているため、S3アップロードを有効にすることはできません。サイトレベルでS3アップロードを有効にすると、アップロードで重大な問題が発生する可能性があります。
app.yml で既に実行済みだと想定しています。
（新しい）アップロードは正しく機能していますか？もしそうであれば、問題はありません。
app.ymlでS3を設定済みです、その通りです。
では、アップロードを確認せずに安全にバックアップとリストアを行うにはどうすればよいですか？
単に「S3アップロードを有効にする」のチェックを外すだけでは機能しません。