我的联合管理员告诉我，他无法从收到的电子邮件中下载备份，因为下载在大约 50% 时崩溃了。
我试了一下，遇到了同样的情况。存档下载运行良好，直到它停止并显示“失败 - 网络错误”。
在 Chrome 上尝试恢复时，返回“失败 - 未知服务器错误”。我上次从该服务器下载备份时没有问题（几个月前）。（这是预期的）
有什么想法吗？
编辑，更多信息：
重现步骤：
- 从电子邮件链接下载备份
- 下载应在大约 30 秒后失败
您好，
我是 Canapin 的联合管理员 
尝试在 Chrome 上恢复时显示“失败 - 未知服务器错误”。我上次从这个服务器下载备份（几个月前）时没有遇到问题。
我想知道这是否是由于一次性链接。您无法使用单个链接下载两次备份。因此，当一次失败后，Discourse 本身可能会取消恢复下载。
1 个赞
我认为你需要改变备份的下载方式
1 个赞
当然，还有其他下载备份的方法，但我更愿意找出并解决这个具体问题 
1 个赞
这很可能是原因，但这绝对不是通过网页浏览器完整下载备份的唯一问题。
作为一项更新，论坛已迁移到另一台服务器（出于无关原因），但问题仍然存在。备份下载（3.3 GB）总是失败。
我遇到同样的问题已经一周多了。在此期间已完全更新了两次，但问题仍然存在。自托管在 IONOS 上。
2 个赞
我已提交一个拉取请求（PR）来解决此问题，具体方法是增加 Nginx 针对 /admin/backups/ 的超时设置，这应该有助于防止在大型下载期间出现“失败 – 网络错误”的中途中断：
1 个赞
刚刚又试了一次。在 1GB 时仍然失败
1 个赞
这太冒险了，可能会导致意外的拒绝服务。
我们应该在那里使用 sendfile，并且 nginx 应该在不需要任何代理的情况下处理它。
1 个赞
已完全更新至 2025.12.0-latest，问题仍然存在。
编辑：我可以通过 WinSCP 或类似工具下载备份，但最好是按宣传的那样工作，并且电子邮件链接 + 浏览器下载能够成功完成。
AI 可能是错的，但也建议将：DISCOURSE_NGINX_PROXY_READ_TIMEOUT: 600 增加到 600 以解决此问题。
1 个赞
我也遇到了这个问题。13GB 的备份大小（在我将所有媒体卸载到 S3 之前进行的最后一次完整备份，以免有人抱怨！）
1 个赞
哇！这绝对是应该通过 SSH 而不是网页浏览器完成的大小
不管做某件事的正确方式是什么，我们只是强调一个有用的内置功能目前已损坏的事实
1 个赞
我是在讽刺
但是启用 secure-media 后，下面的 Python 脚本将无法继续工作
我是否可以建议一些有用的文本，告知管理员备份文件的位置，以防他们想使用客户端下载？
/var/discourse/shared/standalone/backups/default/your_backup_filename.tar.gz
而且这个按钮具有误导性——最好将其标记为“电子邮件下载链接”
它不知道。它不可能知道。这取决于你在 yml 文件中的 docker 配置。它通常在 standalone 中，但也可能在 web_only 中，或者它可能在文件系统的任何位置。
虽然这在技术上是正确的，但我记得在过去十年中没有其他人表达过这种担忧。你觉得它很有误导性吗？如果你认为这会有帮助，你可以在你自己的网站上更改它。
2 个赞