🇨🇳 S3へのDiscourseのバックアップ方法 | Discourse 如何备份到 S3

Discourse と S3 は非常に相性が良く、S3 に慣れている場合は非常に役立ちます。

多くの人の仮想ホストスペースは限られており、リソースも限られています。

S3 を使用してバックアップすることで、スペースをより有効に活用できます。

以下の手順で設定できます。

バックアップ頻度の設定

admin > backup にアクセスし、backup_frequency を 1 に設定します。このパラメータはバックアップの頻度を示し、デフォルトは 7 です。
1 は毎日 1 回バックアップすることを意味します。
7 は 7 日に 1 回バックアップすることを意味します。

一般的なウェブサイトへのアクセスの場合、S3 でバックアップを保存する場合は、毎日 1 回バックアップするのが最善です。

バックアップのバケットとパスの設定

このバケットはプライベートで公開しなくても構いません。注意点として、画像や添付ファイルの保存にも S3 を使用している場合は、そのバケットを設定する際に public を選択する必要があります。

利便性のために、ここで別のバケットを作成することもできます。添付ファイルや画像の保存バケットと混同しないようにしてください。

便宜上、ここに別のディレクトリパスを設定することをお勧めします。Discourse はこのフォルダの下に複数の必要なフォルダを作成します。

これにより、ストレージがより明確で明確になります。

s3_access_key_id と s3_secret_access_key の設定

次に、バックアップデータを保存するために、s3_access_key_ids3_secret_access_key、および s3_region を設定する必要があります。これら 3 つのパラメータは非常に重要で、region を間違えるとバックアップがアップロードできなくなる可能性が非常に高いです。

具体的な設定方法については、Setting up file and image uploads to S3 - sysadmin - Discourse Meta の記事を参照してください。

注意点として、ここではキー ID に十分な権限を付与する必要があります。そうしないと、アップロードできなくなります。

バックアップを S3 ストレージに設定する

バックアップ方法を S3 ストレージに設定します。

このパラメータ選択部分で、Local ストレージを S3 ストレージに変更する必要があります。

バックアップのテスト

すべてが設定されたら、バックアップをテストできます。

バックアップボタンをクリックしてバックアップをテストします。バックアップメニューで、Buckup をクリックするだけです。


表示されるインターフェイスで、アップロードされた画像や添付ファイルを含めるかどうか尋ねられます。

通常はここで Yes を選択します。その後、インターフェイスはログインターフェイスにリダイレクトされ、バックアップ情報がログで表示されます。ログに Finished と表示されるかどうかを確認することで、バックアップが完了したかどうかを確認できます。

さらに重要なのは、S3 アカウントにログインして、最新のバックアップがあることを確認できることです。


時間、サイズ、ファイル名を確認して確認する必要があります。


S3 バックアップを設定することで、Discourse のストレージスペースを拡張し、ほぼ無限のバックアップと無限のストレージスペースを取得できます。ウェブサイトの運用にとって、自動バックアップとアップロードは非常に実用的な機能です。

また、複数のバックアップコピーがあるため、ウェブサイトを復元する際に異なるバックアップポイントに復元できます。

バックアップファイルを Docker から分離することで、日常のバックアップに非常に役立ちます。ストレージスペースの使用量を大幅に削減できます。

画像や添付ファイルも S3 に保存することをお勧めします。これにより、移行やバックアップ復元に大きな利点があります。

詳細については、元の記事 iSharkFly - 飞鲨 を参照してください。

「いいね!」 2

バックアップと添付ファイルが別々のS3にマウントされている場合、バックアップ時に添付ファイルのS3の内容も一緒にバックアップされますか?アップロードされた画像や添付ファイルを含めない場合、バックアップを復元する際に、添付ファイルに使用されているS3の内容はフォーラムで正常に表示されますか?

Discourse のバックアップ内容については、これまであまり詳しく見ていませんでした。

バックアップを確認したところ、以下のことがわかりました。

添付ファイルを AWS のクラウドストレージで利用している場合、バックアップ時に バックアップ時に添付ファイルを含める を選択しても、

AWS にアップロードされた添付ファイルはバックアップファイルに含まれません。

バックアップに含まれる添付ファイルは、ローカルコンピューターに保存されているものだけで、AWS 上にはないものです。

当社のウェブサイトのバックアップサイズを見ると、添付ファイルを含めるとバックアップサイズが 80MB 程度にしかならないことはありえません。

これは、バックアップにはデータベースとローカル添付ファイルのみが含まれていることを示しています。

ダウンロードしたファイルを開くと、2 つのフォルダがあります。1 つは dump で、これは PGSQL のデータベースダンプファイルです。

もう 1 つは upload フォルダで、このフォルダにはローカルにアップロードされた添付ファイルのみが含まれており、AWS に保存されているものはありません。当社にとっては、このフォルダは非常に小さく、ファイル数も多くありません。

これは、コミュニティの運用開始から間もなく、すべての添付ファイルを AWS にアップロードしたためです。

上の画像は PGSQL のダンプファイルの内容を示しており、ダンプファイルから現在の Discourse データベースコンテナで実行されている PGSQL のバージョンを確認できます。

ローカルでデータベースを確認したい場合は、このダンプファイルをローカルコンテナに直接インポートすることもできます。

AWS 復旧の問題

添付ファイルに AWS を使用しているが、AWS の CDN を使用していない場合、本文中の内容は AWS 上の絶対パスアドレスになります。

テーマの MD ファイルでの表示は以下のようになります。

しかし、コンテンツが公開されると、実際の HTML コードは Discourse によって CDN の絶対アドレスに置き換えられます。

したがって、上記の回答に基づき、バックアップ時に添付ファイルをバックアップしない場合、復旧時に添付ファイルの内容には影響しません。

例外

実際には、ドメイン切り替えが原因で添付ファイルも影響を受けることがあります。

以前、ドメインを切り替えたことがありましたが、添付ファイル自体は存在していました。しかし、本文と関連付けることができず、HTML を再構築しても関連付けることができませんでした。

この場合、少し手間がかかりますが、データベースを直接変更する必要があるかもしれません。

ドメインを頻繁に変更しない限り、通常は問題ありません。

より詳細な議論については、以下をご覧ください: Discourse 备份和恢复中有关附件的问题 - Discourse - iSharkFly

ついでにもう一つ質問があります。Amazon S3ではなくCloudflareのR2を使用しており、R2へのバックアップは成功し、Cloudflareでファイルを確認できます。しかし、Discourseの管理画面にバックアップファイルが表示されません。どこに問題があるのでしょうか。


もう一度手動でバックアップを取り、バックアップログを確認してください。

これは、Discourse が R2 ストレージにバックアップを保存した後の状態確認部分のAPI呼び出しにエラーがある可能性が高いです。

ログの内容がすべて表示されているか確認してください。

これは生成されたばかりのスクリーンショットで、すべて正常に表示されているようです。また、R2で最高権限のAPIを作成しました。

私のバックアッププロセスを実行したところ、ログは同じようです。

[2024-07-26 11:56:00] pg_dump: SEQUENCE SET category_custom_fields_id_seq を実行中
[2024-07-26 11:56:00] バックアップを最終処理中...
[2024-07-26 11:56:00] アーカイブを作成中: isharkfly-2024-07-26-115540-v20240723030506.tar.gz
[2024-07-26 11:56:00] アーカイブが既に存在しないことを確認中...
[2024-07-26 11:56:00] 空のアーカイブを作成中...
[2024-07-26 11:56:00] データダンプをアーカイブ中...
[2024-07-26 11:56:00] アップロードをアーカイブ中...
[2024-07-26 11:56:00] S3に保存されているアップロードをスキップしています。
[2024-07-26 11:56:00] tmp '/var/www/discourse/tmp/backups/default/2024-07-26-115540' ディレクトリを削除中...
[2024-07-26 11:56:00] アーカイブをgzip圧縮中、これには時間がかかる場合があります...
[2024-07-26 11:56:05] アーカイブをアップロード中...
[2024-07-26 11:56:09] バックアップの after_create_hook を実行中...
[2024-07-26 11:56:09] 古いバックアップを削除中...
[2024-07-26 11:56:10] クリーンアップ中...
[2024-07-26 11:56:10] ローカルストレージからアーカイブを削除中...
[2024-07-26 11:56:10] '.tar' の残骸を削除中...
[2024-07-26 11:56:10] バックアップ完了をマーク中...
[2024-07-26 11:56:10] ディスク統計情報を更新中...
[2024-07-26 11:56:10] バックアップ終了を 'honeymoose' に通知中...
[2024-07-26 11:56:18] 完了!

次はデータベースバックアップテーブルのレコードの問題かどうかを確認してみましょう。

R2も使っていますか?正常に表示されますか?

私はAWSを使用しています。

この部分は簡単に設定できるはずです。