S3への移行ができず、バックアップからの復元もできません

[teward (Thomas Ward)]

そのため、最初のサーバーからDiscourseのバックアップがあり、システムを新しいシステムに移行しようとしています。

残念ながら、2つの問題があります。

1. リストア中に、1073件中71件のアップロードがS3に移行されていないと表示され、リストアプロセス中にハードフェイルします。

2. メインインスタンスでこれを修正しようとして、投稿をリベイクするなどしても、uploads:migrate_to_s3の仕組みを使用しようとしても、一部のアップロードがまだS3に移行されていないことを示しています。

どのアップロードが移行されていないかについて、migrate_to_s3から詳細な情報を取得する方法はありますか？手動で修正できるようにしたいです。また、最初にアップロードしていたデッド/フェイルしたS3リポジトリを参照している可能性もありますが、その時点で問題が発生し、S3メカニズム（もちろんMinIO）に切り替えただけで、AWS S3側には古いものがまだ残っていました。それをMinIOインスタンスに簡単に移行できるとは思えません。

あるいは、アップロードを自分で強制的に移行したので、リストアメカニズムのS3でのアップロードチェックを無効にする方法はありますか？

[teward (Thomas Ward)]

OK、DBを深く調査した結果、判明しました。元の（実際には、コスト効率が悪いため主に使用されていなかった）S3環境からの残骸（71件のアップロード）のようです。

以下の手順を実行しました。

元のサーバーから:

1. ./launcher enter app

2. sudo -u postgres psql discourse

3. SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%'

   （ExpectedS3DomainGoesHere を S3 設定に使用している実際の URL に置き換えてください）

   これにより、作業に必要な URL が取得されます。

4. URL が異なる URL の古いバケットからのものである場合は、Amazon S3 クライアント（または S3 ストレージバックエンドのクライアント）を使用して、次の操作を行います。

   a. 予期しない URL のバケットをローカルストレージに同期します（利用可能な場合）。

   b. ローカルから新しいバケットにアイテムを同期します。

5. discourse remap OLD-URL-FROM-DB NEW-URL-FROM-DB

   Moving from one S3 bucket to another - #2 by Falco で DbHelper.remap を使用することが推奨されていましたが、discourse の remap 関数で問題なく動作しました。

6. データが移行されたことを確認します。

   rails uploads:migrate_to_s3

7. 再ベイクの時間です！

   rails posts:rebake

8. ‘origin’ マシン/サーバーで再度サイトをバックアップします。その最新の更新をダウンロードします。

新しい宛先サーバーから:

1. Discourse を期待どおりにセットアップし、元のサーバーから新しいサーバーの /var/discourse/containers/ に app.yml などをコピーして、リビルドが適切なプラグインなどを確実にヒットするようにします。

   ローカルバックアップコピーを扱っている場合は、app.yml の DISCOURSE_BACKUP_LOCATION: s3 エントリをコメントアウトしてください。S3 がバックアップファイルを破損させる問題があったため、復元にはローカルアプローチを採用しました。

2. Restore a backup from the command line の手順に従って、バックアップをサーバーに取得し、復元します。リビルド手順も含まれます。

この問題を解決するのは大変でしたが、DB の uploads テーブルを深く調査した結果、解決しました。しかし、これは機能したようですので…

[michaeld (Michael - Communiteq)]

このような状況でよく機能するのは、バックアップを取得する前に、元のインスタンスでS3へのアップロードを一時的に無効にすることです。復元後にS3を再度有効にすることができます。