Cloudflare R2 をメディアアップロードに使用していますが、データベースのバックアップには機能しないと考えています。rclone でバックアップする必要があるファイルディレクトリは何ですか？
以下のトピックが参考になるかもしれません。
Discourse ファイル/ディレクトリを ProtonDrive にバックアップする（R2/S3 メディアを除く）
ステップ 1 — upload:// の意味
upload://
解説
Discourse は、投稿コンテンツ（raw/cooked）に upload://<hash> という参照のみを保存します。ベイク時またはレンダリング時に、Discourse はデータベーステーブル（uploads、post_uploads など）を参照して、これらのハッシュをアップロードの保存場所（ローカル、CDN、S3/R2 など）に基づいて実際の URL またはパスに解決します。
ステップ 2 — コンテナ内のどこに配置されるか
/shared/uploads/default
解説
標準的な Docker インストール（launcher および app.yml を使用）では、コンテナ内の /shared はホストの /var/discourse/shared/standalone からバインドマウントされます。Discourse が永続的に書き込むものすべて（アップロード、ログ、バックアップなど）は /shared の下にあります。
ステップ 3 — ホストファイルシステムのパス
/var/discourse/shared/standalone/uploads/default
解説
外部アップロード（S3/R2）を使用していない場合、これは ProtonDrive に同期してアップロードされた投稿メディアを保持するために必要な主要なパスです。S3/R2 を使用している場合、ほとんどのアップロードはここにはありませんが、一部のファイル（最適化されたバリアント、トンブストーンなど）が残る可能性があります。これもバックアップするかどうかを決定してください。
ステップ 4 — Docker ボリュームマッピング (app.yml)
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
解説
コンテナ内の /shared のすべては、ホスト上の /var/discourse/shared/standalone になります。このツリーをバックアップすると、アップロード、バックアップ tarball、ログ、および（オプションで）ディスク上に保持されている場合は PostgreSQL データも取得できます（ただし、バックアップ tarball は通常、復旧には十分です）。
バックアップする具体的なターゲット（ローカルストア）
最小セット（Discourse の tarball バックアップを信頼する場合）：
/var/discourse/shared/standalone/backups/ # Discourse 生成のフルバックアップ（tarball .tar.gz ファイル）
/var/discourse/shared/standalone/uploads/ # ローカルにアップロードを保存している場合のみ
解説
- tarball バックアップは、Discourse のバックアップ機能によって作成される .tar.gz ファイルを指します。これには、データベースダンプ全体、サイト設定、テーマ、および（選択されている場合）すべてのローカルアップロードが含まれます。外部 S3/R2 に保存されているメディアは含まれません。それらを参照するデータベースレコードのみが含まれます。
- アップロードが S3/R2 にある場合、ローカルでは
/backups/のみが必要で、オブジェクトストレージバケットをバックアップするための別のプロセスが必要になる場合があります。
「いつでも必要になる可能性のあるすべて」セット（ファイルシステムレベルのコピー）：
/var/discourse/shared/standalone/backups/ # フル Discourse バックアップ（tarball）
/var/discourse/shared/standalone/uploads/ # ローカルアップロード/メディア（S3/R2 でない場合）
/var/discourse/shared/standalone/log/rails/ # （オプション）Rails ログ — フォレンジックに役立ちます
/var/discourse/shared/standalone/tmp/backups/ # （オプション）一時的なバックアップステージング（通常は空）
/var/discourse/shared/standalone/postgres_data/ # （オプション）生の PostgreSQL データディレクトリ — 通常は不要
/var/discourse/containers/ # あなたの app.yml およびコンテナの YML ファイル（設定）
/etc/letsencrypt/ # （オプション）ホストで SSL を終端する場合の TLS 証明書
解説
- 生の PostgreSQL データは、tarball バックアップに論理データベースダンプが含まれており、復元にはより安全なため、通常は必要ありません。
- /containers は小さいですが、災害復旧には不可欠です — 設定とボリュームマッピングが保持されます。
- TLS 証明書は、コンテナ外で SSL を実行している場合にのみ関係します。
クイックワンライナーマップ
upload://
↓
/shared/uploads/default (Docker 内)
/var/discourse/shared/standalone/uploads/default (ホスト上)
解説
S3/R2 を使用する場合:
- S3/R2 バケットを別途バックアップしてください（例: Rclone で）。
- 引き続き
/backups/（tarball、db および設定、サイトアップロードを含むが、外部メディアは含まない）および/containers/のバックアップを検討してください。
ProtonDrive スレッドの TL;DR
- ローカルアップロードの場合？ バックアップするもの：
- /var/discourse/shared/standalone/uploads/
- /var/discourse/shared/standalone/backups/ # （.tar.gz 形式の tarball バックアップが含まれています）
- S3/R2 アップロードの場合？ バックアップするもの：
- /var/discourse/shared/standalone/backups/ # （tarball バックアップ：db/config/uploads テーブル）
- 別のツールで S3/R2 バケットをバックアップする
- オプション：完全な DR カバレッジのために /containers/、/log/rails/、および postgres_data
解説
Tarball バックアップ：Discourse のバックアップシステムによって作成される .tar.gz ファイル。論理データベースダンプ、テーマ、設定、および（オプションで）ローカルアップロードを保持しますが、外部 S3/R2 メディアは決して含みません。
ローカルアップロードを保持するためにtarballバックアップに依存したサーバーの移行は3回ありましたが、その度にデフォルトのapp.ymlが異なっていたことを強調したいと思います。
したがって、古いapp.ymlの一部を新しいファイルに手動でコピーして置き換える方が良いでしょう。
コンテナからホストシステムにバックアップファイルを取得するために、docker cpを試したいと思います。それは必要ですか？