# 多个备份计划
**URL:** https://meta.discourse.org/t/multiple-backup-schedules/223312
**Category:** Feature
**Created:** [2022年四月5日 08:36 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312 "2022-04-05T08:36:27Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@Frully](https://meta.discourse.org/u/Frully)
#### Post date: [2022年四月5日 08:36 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/1 "2022-04-05T08:36:27Z")
不确定是回复此处还是发新帖：功能请求 - 为“包含附件”和“不包含附件”设置单独的备份计划。
非常希望能够进行每日小型备份，甚至一天多次备份，因为数据库很小。附件的话，丢失一周的量我也不会非常沮丧，因为附件数量相对有限，而且人们通常可以找到原始来源。这可以在不压垮存储的情况下提高安全性。
我还没看源码，但这可能需要一些大的改动，因为恢复需要是独立的实体，或者至少能够为两个来源提供不同的恢复点。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2022年四月5日 09:47 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/2 "2022-04-05T09:47:05Z")
此请求的建议操作通常是使用某种外部工具进行其他数据库备份。
如果您将上传内容移至 S3，则可以仅进行数据库备份，而不必担心上传内容。
---
### Author:  [@Frully](https://meta.discourse.org/u/Frully)
#### Post date: [2022年四月12日 12:37 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/3 "2022-04-12T12:37:41Z")
还算合理。一旦我开始考虑外部工具，我就会想到“可能搞砸事情的外部方法”，因为它们通常比内置的防傻瓜式（差不多）管理控制台更有可能造成混乱。
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [2022年四月12日 12:56 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/4 "2022-04-12T12:56:22Z")
上次我和其他人问同样的问题时，得到的答案和之前一样：
- 每天一次备份就足够了
- 使用外部工具，例如脚本和 cron
然而，每天一次数据库备份是不够的，每小时一次可能差不多。
任何外部工具都能完成这项工作，这是真的。但是，其他所有应用程序都提供不错的原生备份功能，唯独 Discourse 没有。
我真的很想知道原因是否是：
- “我们就是不想这样做，所以其他人也不需要”
- 技术上确实非常困难和/或成本高昂
当然，总有第三种选择：#Marketplace
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2022年四月12日 13:42 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/5 "2022-04-12T13:42:12Z")
> [@Jagster](#):
>
> 但是其他所有应用程序都提供不错的原生备份，但 Discourse 没有。
如果你想为 WordPress（一个流行的网络平台）进行大量备份，你需要使用一个付费的备份插件，所以也许并非所有其他应用程序都原生支持这一点。至少我就是这么做的，尽管我做出这个决定已经很久了，所以也许是个错误的决定。
原因是大量的备份会填满你的磁盘空间，这是自托管网站宕机最常见的原因之一（我认为这属于“昂贵”的范畴）。所以，如果你有足够的能力来管理海量的备份和磁盘空间，那么你就可以通过很多方式来解决这个问题。如果你想要每小时备份，那么你需要进行仅数据库的备份，而不是几十甚至几百份上传文件的副本。
因此，只有当你将上传文件放在 S3 上时，每小时备份才有意义，这样你就可以进行仅数据库的备份，并且可能将它们推送到 S3，这样你就不必担心本地磁盘空间。然后，想要这样做的自托管网站数量就非常少了。
如果你已经具备了所有这些条件，那么一个可以进行每小时仅数据库备份的插件，最多只需要一两个小时的工作量，或者如果你不知道如何制作插件并且需要花时间研究如何设置每小时任务，可能需要 2-10 小时。
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [2022年四月12日 14:59 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/6 "2022-04-12T14:59:59Z")
> [@pfaffman](#):
>
> 你需要使用一个备份插件
这是真的。WordPress 本身做不了太多。这就是为什么有那么多插件——好的和坏的。
> [@pfaffman](#):
>
> 如果你想使用每小时备份，那么你需要进行数据库备份，而不是备份几十甚至几百份上传文件副本
当然，备份文件或系统本身没有意义，所以不经常备份。数据库本身是完全不同的游戏。如果流量很大，至少应该每15分钟备份一次。
问题很简单：你能承受丢失多少内容。
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [2022年四月12日 15:03 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/7 "2022-04-12T15:03:45Z")
> [@Jagster](#):
>
> 数据库本身是完全不同的游戏。如果流量很大，至少应该每 15 分钟进行一次。
>
> 问题很简单：您可以丢失多少内容。
如果您能承受的最大数据丢失量如此之小，那么您可能需要考虑使用 Postgres 复制解决方案，而不是如此频繁地进行备份。
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [2022年四月12日 15:10 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/8 "2022-04-12T15:10:47Z")
> [@RGJ](#):
>
> 如果您能承受的最大数据丢失量是这么小
我是否不知道还有其他数据？或者您使用的是包含所有文件（系统、Docker/Discourse/等、上传的文件）的更广泛意义上的“数据”？
这些文件可以轻松检索或只需少量费用——嗯，除了上传的文件，但这就是我们拥有 S3 的原因 😉 。
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [2022年四月12日 15:50 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/9 "2022-04-12T15:50:49Z")
不，我是指数据库数据。
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [2022年四月13日 08:12 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/10 "2022-04-13T08:12:42Z")
那么它在尺寸上大多很小，但如果我们考虑论坛本身，它又是最大的。但出于某种原因，我们又回到了这一点：
> [@Jagster](#):
>
> - 每天一次备份就足够了
> - 使用外部工具，如脚本和 cron
我真的很想知道这里的主要问题是技术上的还是心理上的。或者这实际上是商业模式的一部分，如果备份变得容易且有效，托管将失去一个卖点——我不知道是否有这样的销售卖点。我只是想了解为什么更好的备份是一个如此重大的问题，即使它之前被要求过。
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [2022年四月13日 12:19 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/11 "2022-04-13T12:19:45Z")
没有必要怀疑这背后有什么策略或邪恶计划。我不认为人们对更频繁的备份有很大兴趣。如果有的话，早就有人写插件了。这只需要几个小时的工作。我也没有在 #Marketplace 上看到大量对此的需求。
我认为这归结为：
- 对于小型论坛，反正也不会丢失多少数据，因为一天内新增的内容不多，所以更频繁的备份不值得费力。
- 对于大型论坛，更频繁的备份会占用性能和存储空间。
- 对于超大型论坛，您需要考虑其他解决方案（例如复制到热备数据库服务器）。
别忘了，实际_需要_备份的几率也很小。在 Communiteq 的历史（超过 8 年）中，我们只_需要_恢复过一次备份，而且那仅仅是因为我们不耐烦，不想等待几个小时的文件系统恢复。
\*) （不包括应客户要求进行的恢复，他们只是想回滚更改，主要是在非生产论坛中，也不包括我们每月的恢复测试）
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [2022年四月13日 17:58 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/12 "2022-04-13T17:58:08Z")
所以，如果我在这里搜索，找不到任何关于 Discourse 因某种原因崩溃而只能通过恢复备份来解决的主题？
不过很高兴听到 Discourse 如此稳定，不需要最新的备份。嗯，我们知道那并非完全属实。
所以，循环闭合了，我们又回到了起点：
> [@Jagster](#):
>
> - “我们只是不想，所以其他人也不需要它”
> - 技术上非常困难和/或昂贵
>
> 嗯，总有第三种选择：#Marketplace
还有第三种选择。只要我实际上正在为 Discourse 进行一些测试，在这里和我自己那里，我都不愿意为这种基本功能付费。
嗯，我们又在没有团队任何评论的情况下进行讨论了。🤣
---
### Author:  [@Decorbuz](https://meta.discourse.org/u/Decorbuz)
#### Post date: [2022年四月13日 18:23 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/13 "2022-04-13T18:23:16Z")
> [@RGJ](#):
>
> 我不认为大家对更频繁的备份有太大兴趣。如果有的话，早就有人写插件了。
你觉得开发需要多少钱？如果价格合适，如果你有兴趣，我现在就可以出资。💵
> [@Jagster](#):
>
> 嗯，我们又在没有团队评论的情况下讨论了 🤣
CDCK 已经解决了这个问题。给他们一些时间回应就行了。
> [@How to make contributing to Meta more enjoyable?](https://meta.discourse.org/t/how-to-make-contributing-to-meta-more-enjoyable/222806/46):
>
> I’m going to jump in here because I manage the team that supports you both for free here on Meta and paid if you are a customer. I have read every post in this topic. Some of the comments are fair and some are misplaced. We care very much about the open source community, it is the foundation of Discourse, but good business dictates that we prioritise our paying customers. We are aware that as we grow and get busier it is harder to read through every post here on Meta. We have exhaustive discus…
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2022年四月13日 18:46 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/14 "2022-04-13T18:46:44Z")
> [@RGJ](#):
>
> 如果您能容忍的最大数据丢失量如此之小，那么您可能需要考虑使用 Postgres 复制解决方案，而不是如此频繁地进行备份。
这是正解。如果您觉得每日备份不足以满足您的使用场景，请遵循 [使用单独的 PostgreSQL 服务器运行 Discourse](https://meta.discourse.org/t/running-discourse-with-a-separate-postgresql-server/46375) 来运行您自己的 PostgreSQL 实例，并根据需要处理备份和高可用性。
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2022年四月13日 18:46 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/15 "2022-04-13T18:46:49Z")
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2022年四月13日 21:08 UTC](https://meta.discourse.org/t/multiple-backup-schedules/223312/16 "2022-04-13T21:08:34Z")
> [@Decorbuz](#):
>
> 您认为开发成本会有多高？根据价格，如果您有兴趣，我现在愿意资助。💵
我估计在 250-500 美元之间，具体取决于它的可配置程度以及前端需要多少工作。不过我还没真正研究过需要做什么。@RGJ 可能会以更低的价格完成；他完成事情的速度常常让我惊讶。
编辑：哦，这个帖子已经关闭了。如果您有兴趣，可以联系我或在 #Marketplace 发布。