OK、DBを深く調査した結果、判明しました。元の(実際には、コスト効率が悪いため主に使用されていなかった)S3環境からの残骸(71件のアップロード)のようです。
以下の手順を実行しました。
元のサーバーから:
./launcher enter app
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%'(ExpectedS3DomainGoesHere を S3 設定に使用している実際の URL に置き換えてください)
これにより、作業に必要な URL が取得されます。
URL が異なる URL の古いバケットからのものである場合は、Amazon S3 クライアント(または S3 ストレージバックエンドのクライアント)を使用して、次の操作を行います。
a. 予期しない URL のバケットをローカルストレージに同期します(利用可能な場合)。
b. ローカルから新しいバケットにアイテムを同期します。
discourse remap OLD-URL-FROM-DB NEW-URL-FROM-DBMoving from one S3 bucket to another - #2 by Falco で DbHelper.remap を使用することが推奨されていましたが、discourse の remap 関数で問題なく動作しました。
データが移行されたことを確認します。
rails uploads:migrate_to_s3再ベイクの時間です!
rails posts:rebake‘origin’ マシン/サーバーで再度サイトをバックアップします。その最新の更新をダウンロードします。
新しい宛先サーバーから:
Discourse を期待どおりにセットアップし、元のサーバーから新しいサーバーの
/var/discourse/containers/に app.yml などをコピーして、リビルドが適切なプラグインなどを確実にヒットするようにします。ローカルバックアップコピーを扱っている場合は、app.yml の
DISCOURSE_BACKUP_LOCATION: s3エントリをコメントアウトしてください。S3 がバックアップファイルを破損させる問題があったため、復元にはローカルアプローチを採用しました。Restore a backup from the command line の手順に従って、バックアップをサーバーに取得し、復元します。リビルド手順も含まれます。
この問題を解決するのは大変でしたが、DB の uploads テーブルを深く調査した結果、解決しました。しかし、これは機能したようですので…