皆さん、こんにちは。ホストされているDiscourseからセルフホスティングへの移行中です。さまざまなことのテスト実行に成功しましたが、すべてのアップロードを含む実際の移行を実行しようとすると、アーカイブの解凍に数時間かかった後、ダンプファイルを抽出しようとしたときにそのようなファイルまたはディレクトリが存在しないというメッセージが表示されます。そのため、誰かアイデアがない限り、約140GBのアップロードを失う可能性に直面しています。
ログを提供していただけますか？
コマンドラインから復元していますか、それともWebインターフェースからですか？Webインターフェースをお勧めします。
こんにちは。ログは以前のメールに添付しましたが、ここにも再度添付します。まずWebインターフェースで試してから、次にコマンドラインで試しました。バックアップが何らかの形で破損しているのではないかと疑っています。S3にアップロードすると認識されず、ブラウザ経由でアップロードしようとするとすぐに拒否されます。
restore-failure-log.txt (3.28 KB)
そのようですね。ウェブブラウザでアップロードしましたか、それともscp/rsyncでアップロードしましたか？ rsyncで再度アップロードすることをお勧めします。
ジェイ様
先ほどは混乱させてしまい申し訳ありません。この移行プロセス全体を通して、Discourse社ともメールでやり取りをしており、そこにログファイルを添付しました。
エラーを見ると、tarballには実際にはSQLダンプではなく、画像しか含まれていないのではないかと疑っています。このファイルはDiscourse社が私たちの代わりに作成・確認したものです。ブラウザからのアップロードが拒否されたため、http経由でダウンロードし、scp経由でサーバーにアップロードしました。
tarballの内容を確認するコマンドを実行したところ、画像しか含まれておらず、SQLダンプはありませんでした。
tarballのサイズが完全に同じかどうか確認していただけますか？
- CDCKインスタンス上
- ダウンロードしたもの
- scpでアップロードしたもの
アーカイブが切り捨てられていないことを確認するために、tar tfvz を実行すると良いかもしれません。
ディスク容量が不足していないかどうかも確認すると良いでしょう。アーカイブサイズの数倍の容量が必要になります。
少しの間外出しますが、後で確認します。512GBあるので容量は問題ないはずです。バックアップファイルは70GBです。前回作成したファイルよりも数GB小さかったので驚きました。少し大きくなると思っていたのですが。何らかの理由で、SQLダンプが含まれていない可能性が高いです。もし含まれていれば、サイズの違いはこのくらいになるはずです。
進捗状況についてアップデートします。
SQLダンプはダウンロードしたアーカイブに含まれていませんでした。個別にデータベースバックアップを取得し、アーカイブに挿入できるか不明だったため（テストに数時間かかるため）、データベースを復元して移行しました（成功しました）。
現在、Discourseがすべてを廃止し、S3バケット/CDNをシャットオフすると、すべての履歴画像が壊れるという問題があります。
画像はすべて持っており、同じフォルダ構造を維持してS3バケットにすべてアップロードできると考えています。データベースレベルでリンクを一括更新するために、discourse.remap / dbhelper.remapを使用する可能性についていくつかのスレッドを拝見しました。それについて何かご意見があれば、大変ありがたいです！
どうしてそんなことが起こりうるのか想像もつきません。ブラウザがバックアップを解凍して展開し、それを元に戻そうとしたのでしょうか？
discourse.org の人々に、アップロードを含むバックアップを提供してもらうように頼むことができます。それがあなたが望むことです。彼らは include_s3_uploads_in_backup（これは隠し設定の名前ですが、ほぼ間違いなく正確ではありません）をオンにします。
S3 ツールを使って、バケットからすべてをダウンロードし、再度アップロードすることもできます。それに関するトピックがいくつかあります。私はお勧めしません。
最近、100GBほどのバックアップをCDCKからDigital Ocean、ドロップレット、スペースバケット、bunny.net CDNに1000ドルで移行しました。後悔しています。
それはデータベースだけですか？
ああ、tarファイルに画像があるのに、データベースのみの復元を行ったのですか？
彼らが作成した正確なファイルと、Discourse がそれを復元するようにする必要があります。データベースとアップロードが含まれているものです。または、復元コードを見て、画像が新しい場所にマッピングされるように手動で行うことを考案することもできます。Richard がそのためのスキルとツールを持っていると思いますが、その方法でやりたいとは思わないでしょう。
数ヶ月前にテスト実行を行いましたが、すべて問題ありませんでした。今回はバックエンドからのアップロードを含むバックアップをトリガーすることができたので、彼らはその隠し設定をオンにしたままにしたのだと思いますが、約12時間後に失敗したという通知を受けました。その後、Discourseに連絡したところ、彼らがバックアップを作成してくれるとのことでした。数時間後、私が開始したバックアップは完了したようでしたが、Discourseの指示に従ってファイルを破棄しました。その後、バックアップのタイムアウトやエラーの発生など、多くの問題が発生しましたが、最終的に完全なファイルがあると言われました。しかし、ファイルを復元しようとしたところ、アーカイブの展開に数時間かかった後、ダンプが見つからないというエラーが発生しました。tar -tf を使用してファイルを検査したところ、アーカイブ内にダンプがないことが確認されました（他の完全なバックアップを見ると、通常はアーカイブの最初のファイルです）。日曜日だったのでDiscourseに連絡することはできませんでしたが、月曜日の朝までに移行を完了することを約束していたため、データベースのみのバックアップ（約7GB）を取得し、それを使用して移行しました。
Discourseは協力しようとしていますが、日曜日の午後からセルフホスト環境に移行し、すでに移行を完了しているため、彼らが今できることには限りがあります。最も簡単な解決策は、彼らが（有料で）私たちのS3バケットとCDNをアクティブなままにしておくことですが、それは不可能だと言われました。正直なところ、履歴画像は失われることになると思います。
これは修正可能です。S3バケットの内容をローカルのアップロードディレクトリにダウンロードし、データベースでremapを実行して、CDNとバケットのURLをインスタンスのURLに書き換えます。
「いいね！」 1
いくつか問題があります。アップロードされた画像のサイズが、新しいVPSのSSDを最大化してしまいます。また、追加のディスクを接続する機能がありません。サブセットを取得することもできますが、ディレクトリ構造を見ると、これがどのように機能するかはわかりません。また、すでにサイトをローカルストレージではなくアップロードにS3を使用するように設定しています。
では、彼らのS3（またはS3からのバックアップ）をあなたのS3にコピーして、再マッピングしますか？
「いいね！」 1
ええ、それが可能であることを願っています！
「いいね！」 1
ああ、なるほど。ライブになったらもう後戻りはできませんね。削除される前にファイルをS3に移動させることはまだ十分に可能です。
復元を行うためには、常にすべての画像が収まるだけの十分なスペースが必要でした。画像を一度に1つずつコピーすることもできました。ファイルを直接コピーするツールもあると聞いています。
Azure VM を一時的に使用して復元し、大きなディスクをアタッチしてから S3 に戻し、完了後に別のバックアップを取得して、最終的に VPS に移動する（コストを抑えるため）という計画でした。
アップロード全体を含む tar.gz ファイルがあり、これをディレクトリ構造を維持したまま直接 S3 バケットにアップロードできます（最近の標準 AWS アップローダーで可能か、そうでなければ CLI を使用します）。所有権/権限に関する考慮事項があるかもしれませんが、ないかもしれません。
その後はリマップになりますが、discourse.remap と dbhelper.remap の違いはよくわかりません。まず少数のファイルでダミーズインストールでこれらすべてをテストしたいと考えています。
「いいね！」 1