ダウンロードは厳密には必要ないと思われます。ほとんどの人は単一のクラウドインスタンスを実行しており、バックアップ用のS3バケットを持っている場合と持っていない場合があります。バックアップをダウンロードすることは、言及されたようなオフサイトバックアップを作成できるこのグループにとって唯一の方法でしょう。
最近このオープンソース開発者に起こったことを考えると、さらに別のプロバイダーに別のバックアップシステムを構築することさえするでしょう。その有効性に関係なく、毎週または毎月完全に別のストレージの場所/プロバイダーにバックアップを取ることは、素晴らしい警告となります。
@pfaffman、これを追加してくれてありがとう。本当に簡単になりました！（大きなバックアップの復元は、セットアップが何であれ、常に少し緊張して長く待つことですが。）
ちなみに、このパスは間違っていると思います。デフォルトでは web-only になるはずだと思いますか？：
volumes:
- volume:
host: /var/discourse/shared/web-only
guest: /shared
- volume:
host: /var/discourse/shared/web-only/log/var-log
guest: /var/log
追伸：OPをそれに応じて編集しました
ええ。「web-only」というのは、他のすべての文脈で「web_only」となっているだけに、少し紛らわしいですね。しかし、ディレクトリやコンテナの場合は何かが違うのかもしれません。
私に何がわかるというのか… SearXNGと格闘して4時間も無駄にしてしまいました。本来なら5分で終わるはずの作業でした（Dockerのことは本当に嫌いです）。
編集と脱線
本当に😳？「he」と「ck」は禁止用語なのですか？学校では不快感を与えない言葉として教わりました。ということは、彼らは間違っていたということですね、明らかです😂
それは、監視ワードが最初にテストされていたときに追加され、そのまま削除されなかったのかもしれません。
ええ。私もよく混乱します。実際、以前 discourse-setup で 2 つのコンテナ オプションを作成しようとしたときに、アンダースコア/ダッシュの使い方が間違っていて失敗したのも、おそらくそのためだと思います。
さらに悪いことに、それは私のせいだと確信しています。discourse-setup で 2 つのコンテナ オプションを作成したときに何らかのエラーが発生しました (おそらくコンテナにはアンダースコアを含めることができなかったのかもしれませんか？) Ruby はファイル名にアンダースコアを使用するのが好きなので、おそらくそこでアンダースコアを使用したのでしょう。それが原因だと思います。そして、Docker コンテナ名としても有効なホスト名が必要なため、web_only は Docker コンテナ名としては機能しないと思います。
ディレクトリパスではハイフンを好むので、このままで問題ありません。コンテナ名ではアンダースコアの方が理にかなっているので、このままでお願いします。
ちなみに、2つのコンテナ構成を使っている人には、メタにタイトルか自己証明バッジが必要だと思います 
1年ここにいたら、標準インストールは移行が必須になると思います。
シングルコンテナのセットアップに関する既存のドキュメントがそれほど多くなければ、デフォルトにすべきだとさえ主張できそうですが、データベースのメンテナンスが必要になる可能性があることをユーザーに知らせるためのツールが必要になるでしょう。
多くの人が2コンテナのインストールに不満を感じたり、怖がったりしているのをよく見かけます。（最近、誰かが私がインストールした際に作成した2コンテナのインストールをシングルコンテナに移動したいと要望しました。）問題になることは非常にまれで、問題が発生したとしても、準備ができたときにPostgresのアップグレードを延期できるため、実際には手間が省けます。通常、PGのアップグレードはしばらく延期できます（AIプラグインがコアに追加され、その拡張機能が必要になった場合を除きます）。
バックアップが次のエラーの後から失敗し始めました。
[2025-09-09 09:34:50] アーカイブを作成中: blah-forum-2025-09-09-093246-v20250828181952.tar.gz
[2025-09-09 09:34:50] アーカイブが既に存在しないことを確認中...
[2025-09-09 09:34:50] 空のアーカイブを作成中...
[2025-09-09 09:34:50] 例外: tar --create --file /var/www/discourse/public/backups/default/blah-forum-2025-09-09-093246-v20250828181952.tar --files-from /dev/null
tar: /var/www/discourse/public/backups/default/mvertigo-org-vestibular-disorders-support-forum-2025-09-09-093246-v20250828181952.tar: オープンできません: 権限が拒否されました
tar: エラーは回復不能です: 終了します
web_only コンテナ内からパーミッションを確認します。
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 root root 4096 Sep 6 12:37 default
別のインスタンスを見ると、所有権が異なります。
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 9 03:46 default
ここで何が間違っていて、web_only コンテナのそのディレクトリに何を変更すべきですか？標準インストールの場合と同じであるべきですか？
tl;dr おそらく試してみてください
docker exec -it web_only bash
chown -R discourse:www-data /shared/backups
さらに詳しく。
見ずに、次にデータコンテナを再構築してみます。変更がデータコンテナにも適用された（または影響する）ことを願っています。
悪いアドバイスは、...backups/default を世界書き込み可能にして、バックアップの所有権を確認することです。
したがって、webコンテナ（バックアップを実行しているコンテナ）でdefaultをdiscourse.www-dataに変更する必要があると思います。
最近のシングルコンテナはこちらです。
root@forum.mbse-capella.org(app):~$ docker exec -it app bash
root@new-app:/# grep www /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
root@new-app:/# grep discourse /etc/passwd
discourse:x:1000:1000::/home/discourse:/bin/bash
過去のある時点で、ビルドプロセスはすべてのファイルを chown していましたが、非常に時間がかかる可能性があるため、これは削除された可能性があると思います（これはコミットに注意を払ったことに基づくものではなく、感覚に基づいています）。
これは ./launcher enter web_only と同等ですか？
ほとんど。./launcher は最初に git pull を実行します（少なくとも私はそう思っていましたが、そうではないかもしれません？）そして、./launcher よりも docker のタブ補完が機能する可能性が高いです。
また、ランチャーはディスコースディレクトリに配置するのに対し、ルートに配置します。
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 6 12:37 default
これで正しい調整ができたようです。次のバックアップでどうなるか見てみましょう。ありがとうございます！
コマンドラインまたはUXから1つ実行して、機能したかどうかを確認できます。
また、もっと賢くやっていたら：
docker exec -it web_only bash -c "chown -R discourse:www-data /shared/backups"
私は辛抱強く、予定されていたジョブを待ちました（ただし、それを文書化することは非常に役立ちます！）そしてそれは機能したようです。ご協力いただきありがとうございます @pfaffman
それが私たちの違いです。
ええ。再構築ごとに実行されるchownがあったと思います。時間がかかる場合があり、ほとんどの場合不要です（そうでない場合を除きます）。1つのコンテナか2つのコンテナかとは関係ありません。ベースイメージのDebianのバージョンから別のバージョンに移動したことと、新しいバージョンが古いバージョンとは異なるユーザーマッピングを持っていることに関係があると思います。
このセットアップでは docker_manager プラグインは役に立たないのでしょうか。常にアプリの再構築を求めてきます！
「この」が何を指しているのか分かりませんが、このトピックも私が言及したトピックも標準インストール用なので、docker_manager は通常通り機能します。
Docker_manager は別のサーバーへの移行プロセスとは関係ありません。新しいコンテナを構築する必要があるからです。
ベースイメージに変更があった場合、新しいアプリの構築を強制するはずですが、最近はそれがかなり頻繁に起こっていると思います。正直なところ、そこで機能しているメカニズムについてはまだよく理解できていません。
Web_only のブートストラップと (destroy, start) の置換の後、単一のプラグインの変更後に更新しようとしたところ、アプリの再構築を求められたため、このように見つけました。