我附议。它已成为一种现代的通用标准。
对文件进行两次压缩只会白白浪费时间和资源。
不过，要是有人能来做这些不起眼的工作就好了！虽然这活儿没什么光鲜亮丽的地方，但能大大改善自托管用户的体验。
1 个赞
请把我加入那些对此表示感激的名单中，因为备份大小翻倍导致我的备份时不时就会失败，不得不手动清理才能维持备份正常运行。
1 个赞
也许可以标记为 pr-welcome？
虽然这是一个小修复，但导致备份损坏也是非常、非常糟糕的。
3 个赞
那可能就是答案——该怎么做呢？这个分类下并没有提供这个标签
只有像 Sam 这样的人才能决定他会接受哪些 PR。当然，并不是每个 PR 都是被明确请求的。
1 个赞
我们目前正在尝试一些相关的功能。目前还不确定是否会直接涉及这一点，但我们会进一步了解后分享更多信息。
6 个赞
此更改应移除备份所需的“2 倍磁盘空间”要求。同时，它还将 gz 压缩的 CPU 开销分摊到整个备份过程中，而不是在末尾形成瓶颈：
我们还在研究完全弃用外层 .gz 压缩的想法。但由于这涉及格式变更，因此需要格外谨慎。
使用 S3 进行上传的用户可能也会关注这项性能改进，该改进已于昨天合并。
6 个赞
谢谢……希望我们会看到对备份恢复的广泛测试，因为这是一种相当新的做法。
当然可以！
如果社区成员愿意参与测试，可以在站点 YAML 的 version: 字段中使用该分支名称，重新部署后再进行试用。
（建议先在预发布环境中操作，而不是在生产环境中）
2 个赞