最も頻繁なバックアップスケジュールが「1 日 1 回だけ」であることが好きではありません。災害時に、多くの人々が慎重に書いた内容を失う可能性が高すぎるように思えるからです。しかし、HA（高可用性）構成のクラスターを構築したくありません。私のユースケースにはリソース消費が大きすぎます。Discourse に書き込まれたほぼすべてのデータを、時間がかかっても構わないので復旧できるという高い確信を持ちたいだけです。この Discourse は非課金コミュニティ向けの無料リソースであるため、コミュニティがそこに込める価値には敏感ですが、追加コストにも敏感です。データ消失よりも、ダウンタイムの方が許容できます。
私が管理に関わっているある Discourse では、ローカルで配信される画像を設定しました（S3 への画像移動は「片道切符」であり、私はその苦い経験から学びました）。これにより、--watch 機能を使用して minio-client がアップロードをほぼリアルタイムで S3 にストリーミングします。これはホスト側から実行しています（ただし、Digital Ocean Spaces では機能しません。Ceph の制限によりこれが失敗することが判明しました）。これにより、minio-client を使ってすべてのファイルをコピーするだけで復旧が簡単になります。1 つのコマンドで、データベースのバックアップがほぼ 1 日古かったとしても、その瞬間まですべてのデータが復元されます。このパラダイムは本当に気に入っています。
私には、データベース用の WAL アーカイブのストリーミング についても、watch を使わずに、WAL ファイルが完了するたびにそのファイルに対して archive_command で minio-client を呼び出すことで、同じことが可能ではないかと考えられます。ただし、その場合、minio はホスト上ではなく、Postgres と同じコンテナ内に存在する必要があります。
そこで私は考え始めました…
コンテナの YAML ファイルで exec: を使って minio-client を追加し、自分ですべて行うことも可能ですが、discourse/discourse_docker に対して、image/base/install-minio-client と、.mc/config.json を配置し、runit ファイルを追加して、コンテナ設定に基づいた比較的簡単なストリーミングバックアップと復旧を可能にする標準テンプレートを提供することに、皆様はどうお考えでしょうか。これは明らかに上級者向けの設定であり、ドキュメントには 
が付いており、デフォルトでは有効にならないでしょう。しかし、いずれどこかでこの作業を行う可能性が高いのであれば、単に data.yml ファイルをいじるよりも、discourse/discourse_docker 内で実装する方がアクセスしやすいでしょう。コストは、ベースイメージに minio-client を含めることですが、そのサイズは約 21MB です。redis-server バイナリの約 2 倍の大きさです。
これを実行するとの約束ではなく、実際に作業を行った場合に受け入れられる可能性があるかどうか、単に気になったまでです。
追記：代替案として、ファイルをコピーするための別のディレクトリを設け、コンテナ外で minio-client などのツールを使ってデータをリモート先にストリーミングするか、ファイルをコピーする場所に s3fs などのリモートファイルシステムをマウントする方法もあります。これの方がシンプルで柔軟な設定となり、同じ結果が得られ、かつすべての Discourse イメージに minio-client を搭載する重みを伴わないかもしれません。