私は、一切のデータを失うことに関して、少々「コントロールフリーク」なところがあります。日次バックアップだけを見ていると、サーバーに何か問題が発生し、極めて重要になり得る丸一日のデータが突然失われるのではないかと常に感じてしまいます。
専門家ではないので、あまり技術的にならないようにしたいのですが、投稿/追加されたものが別のサーバーに複製されるようなシステムは可能ではないでしょうか？コンテンツを投稿する際にソーシャルメディアプラットフォームが行っているのは、そのような仕組みだと認識しています。
もしDiscourseでそれが不可能なら、時間単位のバックアップの方が少しは安全ではないでしょうか？そのオプションが見当たりません。最低が1（日次）か0（無効）にしかならないようです。
皆さんはどのように対応されていますか？
優れたプラットフォーム上の優れたVPSは、特にアップグレードの間に問題が発生する可能性は非常に低いです。
8年近くフォーラムを運営していますが、データ損失は一度もありません。
毎日のバッチ処理は、ほとんどのセルフホスターにとってのトレードオフとして設計されています。
それは比較的単純なシステムであり、多くのスペースや処理能力を要求しません。
ほとんどの人にとって、それをより頻繁に行う価値があるとは想像できません。
オンラインでのクラッシュのためにバックアップを使用したことは一度もなく、新しいサーバーへの移行のためだけに（より小さなサーバーでは手狭になった場合！）使用するだけです。
YMMV（あなたの経験は異なるかもしれません）
しかし、より頻繁な設定が必要だと考えるなら…セットアップをカスタマイズする準備をし、そのカスタマイズを維持する準備をする必要があります（これには、その方法を学ぶことや、誰かに助けを求めることが含まれます）。
バックアップとレプリケーションは異なるものです。
バックアップは、ある時点でのデータのスナップショットを提供します。復元ポイントを提供します。
レプリケーションは、すべての操作を別のシステムに分散させることで、複数の場所にデータを持つようにするものです。削除もレプリケートされます。
真に耐障害性を高めたい場合は、両方が必要です。（さらに多くも…）
したがって、レプリケーションは現在のデータを複数の場所に持つという問題しか解決しません。バックアップは、システムを指定された時点に復元する方法を提供します。
Discourse はストレージに 2 つのメカニズムを使用します。
PostgreSQL データベースに保存されているデータをバックアップおよび/またはレプリケートするには、PostgreSQL のドキュメントでその方法を確認できます。バックアップについて、およびレプリケーションを参照してください。
添付ファイルはもう少し厄介です。S3 に保存する場合は、S3 バックアップを使用できます。ローカルに保存されたファイルの場合は、さまざまなローカルシステムオプションを使用できます。
フルバックアップの作成は、データ量によっては重いタスクです。そのため、頻繁に実行するのは容易ではありません。Discourse の標準的なバックアップ手順は、フルバックアップを作成することです。データを失うリスクを本当に減らしたい場合は、他のオプションを探す必要があります。
1 つのオプションは、ホスティングサービスによって提供される可能性があります。ボリュームスナップショットです。これは、ボリュームに保存されているデータの「瞬時」コピーを作成する方法を提供します。これにより、その時点までボリュームを復元できます。ボリュームスナップショットは、使用されているファイルシステムに応じて OS 内でも利用できる場合があります。（たとえば、btrfs はこれをサポートしています。）
それに加えて、PostgreSQL のドキュメントでは、データベースのより継続的なバックアップを作成する方法についても説明されており、データベースの優れたポイントインタイムリカバリが可能になります。（バックアップをオフサイトに送信することを忘れないでください。）これはフルバックアップよりもはるかに高速です。
より粒度の高い添付ファイルのバックアップについては、フル+差分バックアップの管理を可能にするさまざまなバックアップツールを使用できます。たとえば、duplicity です。または、rsync（削除なし）を使用することもできます。スナップショットの間では、ファイルを失う可能性があります。削除なしで S3 を使用する方が安全です。ファイルはすでに別のシステム上にあるためです。
結論として、Discourse の標準的なバックアップメカニズムは、より頻繁なバックアップスケジュールには適していません。より多くのバックアップが必要な場合は、標準の PostgreSQL バックアップ/レプリケーション機能、S3、ボリュームスナップショットなどの組み合わせを使用してください。
私のサイトでは、定期的なバックアップに Discourse のバックアップシステムを使用していません。まだ毎日のバックアップはありますが、pg_dumps と duplicity の設定の組み合わせを使用しています（backupninja 経由で調整されています）。
私はデータベースのバックアップを4時間ごとに行っています。これは、投稿が失われる可能性があっても許容できる時間枠です。比較すると、私のeコマースは5分ごとにバックアップを実行しています。
1日1回では不十分です。最大24時間分の失われたトピック/投稿の価値は、あまりにも大きすぎます。
静かなフォーラムであれば数日ごとのバックアップでも問題ないかもしれませんが、非常に活発なフォーラムでは1時間でも大きな損失と感じるかもしれません。しかし、障害の発生確率も考慮する必要があります。仮に年に一度1時間分の投稿を失うとしたら、それは非常に気になるでしょうか？10年に一度ならどうでしょうか？リスクに対する考え方は人それぞれです。
投稿よりもさらに大きな損失は、24時間以内に作成されたすべての新しいアカウントかもしれません。
特に、Discourseが他のアプリケーションや他の統合のためのSSO（シングルサインオン）プロバイダーとして使用されている場合です。
この「日次で0回」という回答は正しくないと思います。
ゼロはバックアップを無効にします。この設定は、バックアップ間の日数を決定するだけです。
@Jagster さんのカスタムの頻繁なデータベースバックアップは、毎日のバックアップでは不十分な場合に必要としている、より適切な解決策のように思われます。
ええ、私はAIが人々にどれほど危険なほど間違った提案をするかを強調していただけです。
もし誰かがそれを見て、言われたことを実行したとしたらどうでしょうか？ 
これは https://meta.discourse.org/t/staging-test-server-ignored-the-environment-variable/390085/2?u=falco から引用されたもののようです。投稿をより明確にするために更新します。