私の共同管理者から、受信したメールからのバックアップのダウンロードが約50%でクラッシュしたためダウンロードできなかったと聞きました。
私が試したところ、同じ状況になりました。アーカイブのダウンロードは順調に進みますが、途中で「失敗 - ネットワークエラー」で停止します。
Chromeで再開しようとすると、「失敗 - 不明なサーバーエラー」と表示されます。前回このサーバーからバックアップをダウンロードしたとき（数か月前）は問題ありませんでした。（これは想定内です）
何か心当たりはありますか？
編集、追加情報：
再現手順：
こんにちは。
私はCanapinの共同管理者です:slight_smile:
Chromeで再開しようとすると、「失敗 - サーバーエラー」と表示されます。前回このサーバーからバックアップをダウンロードしたとき（数ヶ月前）は問題ありませんでした。
これはワンタイムリンクが原因ではないかと疑問に思っています。1つのリンクでバックアップを2回ダウンロードすることはできません。そのため、一度失敗すると、Discourse自体によってダウンロードの再開がキャンセルされている可能性があります。
バックアップのダウンロード方法を変更する必要があると思います。
バックアップをダウンロードする他の方法もありますが、この特定の問題を特定して修正したいと思います 
おそらくこれでしょうが、Webブラウザ経由でのバックアップの完全なダウンロードを妨げている唯一の問題ではありません。
アップデートとして、フォーラムは別のサーバーに移行されました（無関係な理由による）が、問題は解決しません。バックアップのダウンロード（3.3 GB）は常に失敗します。
別のフォーラムからバックアップをダウンロードしようとしましたが、同じ問題が発生しました。
ご自身のインスタンスで再現を試していただけますか？両方のサイトで、ダウンロードは30秒後に失敗します。
これは私だけの問題ではないと確信しているので、Bug に移動します。
この問題は1週間以上続いています。その間に2回完全にアップデートしましたが、問題は解決しません。IONOSでセルフホストしています。
これを解決するために、Nginxのタイムアウトを特に/admin/backups/に対して増やし、より大きなダウンロード中の「失敗 – ネットワークエラー」による途中終了を防ぐようにするPRを提出しました：
今試しましたが、まだ1GBで失敗します
これはリスクが高すぎます。意図しないサービス拒否（DoS）のリスクが生じる可能性があります。
代わりに sendfile を使用し、nginx がプロキシなしで処理できるようにすべきです。
2025.12.0-latestに完全に更新しましたが、問題は解決しません。
編集：WinSCPなどを使えばバックアップをダウンロードすることはできますが、宣伝どおりに機能し、メールリンクとブラウザダウンロードが正常に完了すると良いでしょう。
AIはおそらく間違っていますが、この問題を解決するためにDISCOURSE_NGINX_PROXY_READ_TIMEOUT: 600を増やすことも推奨しています。
私も同じ現象に遭遇しています。13GBのバックアップサイズです（誰かが文句を言う前に、すべてのメディアをS3にオフロードする前の最後のフルバックアップです！）
うわー！これはウェブブラウザではなく、SSH経由で行うべきサイズですね。
正しい方法が何であるかに関わらず、便利な組み込み機能が現在壊れているという事実を指摘しているだけです 
皮肉を言っていただけです
ただし、以下のPythonスクリプトは secure-media を有効にした後も動作し続けないでしょう
管理者がクライアントでダウンロードしたい場合に備えて、バックアップのファイル場所を伝える役立つテキストを提案してもよろしいでしょうか。
/var/discourse/shared/standalone/backups/default/your_backup_filename.tar.gz
また、このボタンは誤解を招く可能性があります。「ダウンロードリンクをメールで送信」とラベル付けした方が良いでしょう。
それはわかりません。知ることはできません。それはymlファイルでのDockerの設定に依存します。通常はstandaloneにありますが、web_onlyにある可能性もありますし、ファイルシステムのどこにでもある可能性もあります。
それは技術的には正しいですが、過去10年間に他の誰かがその懸念を表明した記憶はありません。あなたはそれが非常に誤解を招くと思いますか？ご自身のサイトで、それが役立つと思うなら変更できます。