「復元」失敗: 不一致を無視できます

このトピックは、4投稿目以降の「復旧失敗」に発展し、現在はそれが主な問題となっています。最初の4投稿は無視して構いません。

アップロードを数年前に/最初にAWS S3に設定しました。
バックアップにS3アップロードを含めるオプションを有効にしたことがない(私の知る限り)にもかかわらず、昨日、「アップロード」をバックアップに含めることを選択したところ、ログに次のものが表示されました。

いくつか奇妙な矛盾があり、困惑しています。

  1. 昨日夕方、管理設定で「アップロード」をバックアップに含めるオプションをオンにしました。そして、ローカルの「共有アップロード」フォルダをWinScpで表示したところ、1xフォルダに100ファイル未満しかありませんでした(他の2x、3xフォルダは存在しません。必要であればSSを共有できます)。なぜバックアップログは3Kファイルがダウンロードされたと表示しているのでしょうか?(「ダウンロード失敗」はこれらのログの別の頭痛の種/問題ですが、それは「別」の問題です)。さて、ローカルストレージからファイルをダウンロードしている場合、それほど多くのファイルはどこに存在するのでしょうか?そして、S3からダウンロードしている場合、a)なぜそこからダウンロードしているのでしょうか?なぜなら、RailsコンソールでS3データをバックアップに含めるオプションを変更したこともなく、ymlファイルのEnvセクションにも同様のオプションを作成したこともないからです。
  2. 次に、今日Railsコンソールでそのオプションを「True」に変更しました。そして今、バックアップジョブを実行したところ、同じ約3.2Kファイルのダウンロード、約100件の「ダウンロード失敗」が表示されました。しかし、AWS S3バケットを確認したところ、約3GBのファイルが約10倍の32Kファイルありました。なぜそれらのファイルをすべてダウンロードしないのでしょうか?
  3. これらのデータをすべて照合/同期し、発生している矛盾やその場所を知る方法はありませんか?
  4. 今、私は非常に困惑しています。どうすればよいでしょうか?私の最終的な目標は、(高すぎる)AWSストレージをより安価なバージョン(私のVPSが実行されているHetzner自体は非常に安価なので、プライマリサーバーのストレージを増やすこともできます)に移行することです。

ありがとうございます。何か方向性を示してください。

「アップロード」フォルダ(Aws S3バケット内)が3GB(3.2kファイル)を超えていても、なぜバックアップが1GB未満(バックアップにダウンロードされたファイルはわずか2.9kファイル)になるのでしょうか?Railsコンソール経由で「include_s3_uploads_in_backup」オプションを有効にしてもです。

その設定では、ファイルを一時ディレクトリにダウンロードし、バックアップに含めます。アップロードディレクトリには配置されません。アップロードディレクトリに配置するには、バックアップを復元する必要があります。何か問題が発生した場合に元のサーバーがそのまま残るように、新しいサーバーで実行することをお勧めします。

ファイルがいくつか欠落している可能性があります。画像が欠落している投稿はありますか?別の可能性としては、アップロードテーブルに、投稿で参照されなくなったアップロードが含まれているため、それらの欠落した画像は問題ないということが考えられます。

100程度であれば、おそらくそれほど大きな問題ではありません。

あるいは、バグによって保持されるべきファイルがクリーンアップ(削除)された可能性もあります。

ダウンロードしたファイルを確認するには、バックアップファイルをダウンロードして、何が含まれているかを確認する必要があります。バックアップを新しいサーバーに復元して、どのように機能するかを確認してください。

「いいね!」 1

しかし、主な点は、S3の「Uploads」フォルダだけで3.2GBと32Kファイルしかないのに、なぜバックアップがわずか3100ファイルで1GB未満なのですか?(バックアップログには、約10%、3Kファイルしかダウンロードしていないことが明確に示されています)。

[新しいディスコースセットアップを別のドメインで作成してこれをテストするのは非常に面倒ですが、スナップショットを作成し、必要に応じて、非常に忙しくない私のサイトを5分以内に手間なく元に戻すのは非常に簡単だと思います]

さて、Rails Cでオプションを変更した後でも、DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true という行をymlにも追加すれば、すべてのアップロードをAws S3から呼び出せるのではないかと考えました。

しかし、ymlでこのオプションを変更し、コンテナを再構築してバックアップを実行した後、バックアップログに同じような行(約100件の失敗を伴う3000件のメディアダウンロード)が見つかりました。

そして、リストアを試みたところ(まだ管理設定でアップロード/S3設定を変更していませんでした)、エラーが発生しました。

Full Log:
![image|690x389](upload://fN6fSsRv2l37aN7O2Mxie7kwx8V.png)

そのため、画像をS3バケットにアップロードしようとします。

tarファイルを開くと、エラーメッセージが表示される100個を除いて、すべての画像が含まれていることがわかります。

「いいね!」 1

image
S3へのアップロードを無効にし、1GBのバックアップ(バックアップはまだAWS S3にあります)を復元しようとしましたが、再び失敗しました。何が問題なのでしょうか?

また、復元に失敗した後、ログアウトされ、再度ログインすると、スタッフ以外のメールが無効になっているというバナーが表示されました。メールで受け取ったリンクからログにアクセスしようとしましたが、ファイルが見つからない/アクセスできません(設定したエラーページが表示されます)。

復元を試みていたとき、ログアウトされる直前に、これらのログメッセージが表示されていました。

[2024-08-19 04:12:58] 'Bathinda_Helper' has started the restore!
[2024-08-19 04:12:58] Marking restore as running...
[2024-08-19 04:12:58] Making sure /var/www/discourse/tmp/restores/default/2024-08-19-041258 exists...
[2024-08-19 04:12:59] Downloading archive to tmp directory...

後続の「FAILED-restore」の試行で、サインアウトされる直前にログリンクをクリックすることができました。以下がそのログです。
log- failed restore.txt (98.9 KB)

いくつかの実験を行ったところ、新しいアップロードはローカルのUbuntuサーバーに実際に作成されていることがわかりました。しかし、S3からローカルへの復元が失敗しています。ただし、確認した投稿の一部では、画像がS3から引き続き表示されています(それらは欠落していません)。

ご指導をお願いします。

復元がまた失敗しています。

また、「復元失敗」の後、同じ管理者でサインインしても、「Log.txt」添付ファイルにアクセスできません。「ページが利用できません」または「私のセットアップエラー」ページが表示されます。

コマンドラインで restore を試してみて、tmux や screen を使用するとログをスクロールバックできるようになります。

「いいね!」 1

この投稿から、指示通りTmux経由で以下を試しましたが、この方法で失敗しています。

また、「data」と「Web_only」のコンテナがありますが、どちらを復元すればよいでしょうか?

web_only コンテナから復元します。実行しているとおりです。

最初のコマンドで復元を正常に有効にしました(別の方法で再度試す理由がわかりません)。次に以下を実行します。

 discourse restore
「いいね!」 1

実際、上記で参照された投稿のスクリーンショットと同じことをしようとしました。とにかく、今はこの「Discourse restore」のみを行います。

私の理解では/願わくば、どこかにあるバックアップ(.tz)ファイルへのパスを指定する必要はなく、ローカルサーバーのバックアップフォルダから自動的に取得されるはずです。

「いいね!」 1