1回のバックアップではリスクが高すぎませんか？サーバーに何かあった場合、最後のバックアップが昨日行われたとしたら、どうすればいいですか？昨日から今日にかけて登録されたユーザーは、もう登録されていないのですか？バックアップの頻度を上げる、例えば1時間ごとにする方が良いと思います。しかし、その場合、バックアップを行う前にサイトを読み取り専用にする必要がありますか？よろしくお願いします！
「いいね！」 3
これも、もう一度お願いします。Discourseは、データベースのバックアップを1日1回しか自動化できない唯一の動的なシステムです。
コアの部分では、すぐに変更されるとは思いません。週に複数回のデフォルトへの変更について話し合ったこともありますが、実現しませんでした。
良いかもしれないのは、データベースのみのバックアップを数時間ごとに実行するサイト設定を追加するプラグインです（圧縮できないアップロードの山のようなコピーを、それらのフルバックアップすべてに保持する必要はありません）。もし興味があれば、プライベートメッセージを送るか、マーケットプレイスで質問してください。
「いいね！」 2
より優れた災害復旧が必要な場合は、Running Discourse with a separate PostgreSQL server に従い、PostgreSQL を自分で実行して、ライブ同期レプリカ、ポイントインタイムリカバリ、より頻繁なバックアップなど、必要な高可用性を正確に制御することを推奨します。
「いいね！」 3
このポリシーの理由をお伺いしてもよろしいでしょうか。技術的な理由でしょうか、それともより多くのクラスを望んでいるのでしょうか。高トラフィックのフォーラムでは、バックアップ間の24時間のギャップは非常に重要な問題です。それとも、これは有料顧客にのみ提供されるものなのでしょうか？
「いいね！」 1
Discourse を別の PostgreSQL サーバーで実行すると、別のサーバー上にあることで速度が低下しますか？
「いいね！」 1
はい、それは一つの解決策です。ただし、アプリケーションとしては非常に珍しい解決策です。PHP/MySQLの世界では、cronを使用してデータベースをバックアップするのは非常に簡単ですが、これもまた、その世界では、プラグインがあってもなくても、どのアプリケーションでも自分で実行できます。
はい、私は平均的なエンドユーザーよりも少し上ですが、DockerやRailsなどがどのように機能するかについては非常に限られた理解しかありません。そのため、一般的なタスクがほとんど不可能に近い状況は、本当に理解するのが難しいです。もちろん、それは私の限界のためかもしれませんが、これについて疑問に思っているのは私だけではありません。
さて、近い将来も中期の将来も、データベースのバックアップを簡単に取得できないことは理解しました。
「いいね！」 1
cronでPostgreSQLのバックアップを設定することもできます。ここも何も違いはありません。
関連するような方法では低下しません。私たちがホストしているすべてのDiscourseインスタンス（ここにあるものも含む）は、専用サーバー内のデータベースを使用しています。
「いいね！」 2
理解を深めるために、2つの質問をさせてください。
- データベースは、すべてを復元するために必要な唯一のものですか？設定を通じて毎日行われるバックアップは、データベースのみをバックアップしますか？
- データベースのバックアップを行う際に、フォーラムを読み取り専用モードにする必要がありますか？それとも、いつでも問題なく行うことができますか？
前もって感謝いたします！
「いいね！」 2
設定はデータベースに保存されます。
技術的には、uploadsフォルダとapp.ymlサイト定義もバックアップする必要があります。ただし、通常はapp.ymlをソース管理下に置き、uploadsをオブジェクトストレージサービスに配置することで対応します。
読み取り専用にする必要はありません。
「いいね！」 4
データベースを別のサーバーに配置し、そのデータベースのバックアップを1時間ごとに実行すると仮定します。管理パネルの設定から、app.ymlファイルとuploadsフォルダを含むファイルのみをバックアップした場合、データベースはバックアップに含まれないということですよね？ @Falco
「いいね！」 1
バックアップには、データベースとアップロード（S3上にない場合）が含まれます。Discourseはapp.ymlを読み取れないため、バックアップには含まれません。
ほとんどの人におすすめなのは、バックアップをS3に保存し、app.ymlは緊急時に取得できる場所に置いておくことです。そうすれば、app.ymlを使って新しいコンテナを構築し、コマンドラインから復元できます。しかし、他のツールでPostgresのバックアップ/復元を行う技術力があり、S3に画像がある（または他の方法でバックアップしている）場合は、コンテナを再構築するだけで復旧できます。
あるいは、複数のPostgresサーバーを継続的にミラーリングし、プライマリがダウンした場合に自動的にバックアップに切り替わるように手配することもできます。
Discourseが提供するよりも頻繁なバックアップを提供する方法は無数にあります。より頻繁なバックアップが必要な場合は、他の方法で行う必要があります。
「いいね！」 2
もう一つの点は、リスクとメンテナンスです。すぐに利用できる日常的なソリューションを使用する場合、自分で設定する場合よりも堅牢で信頼性の高いバックアップソリューションになる可能性が高いです。自分のソリューションで何か問題が発生し、手遅れになってから初めて気づいたらどうなるでしょうか？少なくとも標準的なソリューションでは、毎日テストしている何百ものサイトがあります。
4年間、複数のサイトで破損を経験したことが一度もないことを考えると、そもそもバックアップが必要になるリスクも低い…
他の人がより大きなリスクを指摘できるかもしれませんが、おそらく最大のリスクは、サーバーがいっぱいになることによる問題でしょう？したがって、スペースに注意してください？アラートを設定しますか？
「いいね！」 3
理解した限りでは、すべてを別々に保持するのが最善の方法です。
Discourseを実行するためのメインサーバー。次に、PostgreSQL用のサーバーと、アップロード用のS3（または他のオブジェクトストレージサービス）です。
app.ymlファイルは頻繁に変更されないように思われるため、一度保存すれば十分です。あるいは、月に数回程度です。
これにより、ファイルをより整理された方法でバックアップすることもできます。
もしそうなら、コアに複数の日次バックアップを実装しないという彼らの選択は理にかなっていると思います。一方で、複雑なニーズを持つ人々は、そのような特別な構成を行うでしょう。そして最終的には、インストールをやり直し（app.ymlをどこかに保存しておく）、データベースとS3に再接続してデータをアップロードするだけです。バックアップはこれら2つのサーバーに個別に保存されているため、私にとっては管理が容易です。これは非常に公平な解決策だと思います。
皆さん、説明ありがとうございました。
「いいね！」 3
こちらにも別のスレッドがあります: Configure automatic backups for Discourse - #113 by Tris20
@pfaffman がそこでいくつかの推奨事項とリンクを提示しています。これが、より頻繁なバックアップのスケジュール設定の方法としてコマンドラインに私を導きました。これは私にとってはかなり合理的な解決策です。
このソリューションを使用すると、すべてを Python スクリプトにまとめることで、同時に yaml ファイルなどのコピーをスケジュールすることもできることに注意してください。
「いいね！」 2
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.