他们的数据库太庞大了，几十的VPS是搞不定的
别说几十了，估计得几千块的

没那么大，前两年我扫过全站附件*^_^*，印象中也就十几个g还是二十几G。单纯搞个垃圾vps做数据存储，几十G的数据量，几十块足够了。
我有个物理机不到200，都2t的固态盘，现在服务器很便宜的

既然那么便宜，那楼主你何不直接捐助一点？建议来建议去的有何意义？你直接捐助论坛不就好了？反正你自己说的便宜！

GLWCNM 既然那么便宜，那楼主你何不直接捐助一点？建议来建议去的有何意义？你直接捐助论坛不就好了？反正你自己说的便宜！

我不干，他也不会接受。

需要把带宽算进去的 几十块都是3M 5M的  就算只备份附件  每小时打包十几G 往峰值几百K的机器里传  一天也传不完一个小时的  
几十块过于理想化  十几G备份进去 站出了问题需要备份的时候都拿不出来

看来都接触不多吧。8美元，1t的盘，1g的带宽，不限流量，还是物理机不是虚拟机，遍地都是，6美元2t的盘，vps，也有的
很贵么？
我自己用的3代e3，32g内存，企业级1t * 2固态盘，物理机，也不到20美元。
理想化不理想化的，结论性的话就别轻易讲出口了。

而且，文件同步是增量，又不是每次一个完整包，rsync这种运用几十年的小工具，也算常识了。增量打包，tar之类的本身就可以把若干时段以来新增/修改过的文件进行增量打包，似乎也比较常识。
数据库做实时复制的话，打包的时候就是在备份机上面本机打包了，并不占用带宽，数据库自身就有的实时复制功能我不记得有多久，但早在90年代我是用过的。

理想化，还过于？不至于吧？

既然便宜，那你资助一下又有什么关系呢？又不肯资助，还那么多要求，那么多建议。你又没试过，怎么知道人家就不会接受了？

你这么慷慨，为何又要慷他人之慨呢？你为什么不资助？
什么叫要求？我提过任何要求？请你指出。
建议而以，不接受无妨，那你又做了什么？慷慨？

你是谁？
是不是提个建议都需要你许可？

我也算半个信息安全从业者吧。我的想法是这样的：

1. 是否应该做主从备份？

这一点的答案是肯定的。无论怎样，数据无价。备份永远不嫌少，有一份冗余就有一份保证。

2. 具体怎样的主从备份？

这一点就是比较头疼的了。我们需要拆成以下可能的情况：

2.1. 利用对应数据库的热备份工具导出

一个符合直觉的方法是直接使用数据库的 dump 工具定时生成一份数据库备份并传输到远端。
这个方案也是我目前在我的个人站点上使用的。实测的情况是：这么做还是有点“贵”的，主要是因为数据库本身其实很大。
楼主提到了附件不大，这点确实：毕竟每个主题平均下来可能也就只有几个 10kB 的种子文件作为附件；但是楼主忽略了数据库，承载这个论坛的基础，其实是很大的。

单纯地 dump 数据库还有一个比较尴尬的情况是并不是所有数据库都支持增量式 dump. 所以很多时候 dump 文件大小会滚雪球一般增长。这可以认为是不可接受的。

2.2. 利用 MySQL/MSSQL/PostgreSQL/... 的内建主从关系

不过现代数据库很多都内建主从备份功能。那么能否直接使用数据库内建的主从能力实现复制呢？
想法上而言很美好：我们可以增量式地传输更改，可以不用手动执行同步，对于用户而言这种主从复制是透明的。
我们甚至可以跨可用区配置从数据库作为只读数据库来达到更低的访问延迟……
但在大多数数据库实践中，跨广域网的主从复制都一直是一个很头大的东西。GitLab 和 GitHub 的前车之鉴可做参考。

（主要问题在于：主数据库能否及时将 WAL 发出？从数据库能否及时将 WAL 接住？如果从数据库失步了，怎么重新从主数据库上同步？如果主数据库 down 了，要不要做 fail-over?）

2.3. 利用 rsync 等工具备份附件

楼主提出用 rsync 来增量式备份附件，这点应该是可行的。不过取决于数据库的具体实现，附件可能是直接作为 BLOB 存储在数据库中的。
如果使用 rsync 来增量备份附件的话，对于数据库事务同步这一块就不是很好保证。
不过现实情况是我们只要保证备份的最终一致性，所以这部分就当是我在吹毛求疵吧。

2.4. 比没有备份更糟糕的是备份不管用但你不知道

备份这种东西，并不是一蹴而就的。它需要你时不时地检查和测试一下。
不然当真的需要执行数据恢复的时候，你可能会尴尬地发现自己只有来自过去好几年的第一份备份可用。

2.5. 当那一天真的来临

当我们不可避免地遇到主数据库爆炸的时候，我们怎么才能从备份中恢复呢？
大部分现代数据库在主数据库爆炸时会尝试将从数据库提升为主数据库（如果我们选择了 2.2 的备份方式），
而如果从数据库是跨广域网的，那么整个站可能会因为极高的数据库读写延迟而原地爆炸。（参考 GitHub 数据库失效事件）
运维人员则不得不一点点地从从机中复制数据到主机，并重新建立主从结构才能让站点恢复。
这里还是用 GitLab 的前车之鉴：他们当时炸掉了整个主数据库和从数据库，不得已只能从冷备恢复；而尴尬的是冷备的出站带宽很小，所以恢复用了特别长时间（而且还丢了一部分数据）。

当然，最终站点可以被恢复，就是可能会需要两三天。这个部分理应可以取舍，不过……

3. 被黑不一定意味着数据的全量丢失——相反，你可能会又多一份（不想要）的全站备份

对于这样的大站点，攻击宕站的风险虽然高，但是数据泄露则是更隐秘而棘手的问题。
当我们设置好了多端备份后，不仅主站会有泄露风险，从站也会有不同的泄露风险。
我们当然可以为各个从机配置合适的安全策略，这自然也是一笔开销。
便宜的主机总归还是有不可控的风险，比如随时跑路，而跑路之后的数据怎么保证销毁就不得而知了。

比较过分的情况是有些恶意程序不仅仅会破坏主数据库，还会破坏从数据库。如果仅采用 2.2 方案进行主从备份的话，
被这种程序攻击无异于无备份。所以 2.1 方案似乎也是逃不掉的——冷备，只追加，不删除。

4. 「那是一个很糟糕的冬天么？」「不，那是一个很美好的冬天——我们在那个冬天里丢失了无数棘手的文件」

这部分就是我以小人之心度君子之腹的揣测了。
BT 之家毕竟本身就带着一些额外的属性，所以有些时候为了能让站点继续存在下去，或许选择「数据丢失」是最好的方案。

结论：备份固然是好想法，但是正确地执行备份并不是一个简单的任务。任重而道远！

有些东西想想是好的，要真付诸实践，不是张口就来的。山外有山人外有人，BT团队运营那么多年，我不相信技术上没有考虑过你说的这些，毕竟不是运营团队的人都无法了解网站具体的真实情况。

你复制那么多，只是我说的一部分。。。
我提过了实时复制，周期性打包，增量同步，等等。
数据库增量备份，没意义，最好是完整打包。但一定要做，倒也简单。
公网主从，我做过比较极端的是美国西部到国内中原地区，延时半秒以内。但备份若放在国内的问题在于带宽贵，且遇到灾难性故障的时候无法快速恢复，无法最大限度缩减离线时间。我这两天核实了一下我所说的备份机的成本，美国的话，6美元2T的盘，g口，几个t流量，足够。8美元的物理机，g口，1t的盘，欧洲。我之前所说的成本，没毛病。
rsync主要针对于文件系统，不适用于数据库。
被攻击，他前面挂了cdn的，这个可以无视。他应当担心的是入侵，这个我已提供应对方案。
备份机应当异地，且不提供对外服务，说白了就是一个月两包烟钱，换一个极端情况下的后手，不至于像btbtt那样出点事就一切归零。

付诸实践，说得好，我算是第一批职业黑客，20多年了，也算是第一批信息安全从业人员，也有19年。人外有人这个话，在这个领域，不适合我。
也不必觉得运营那么多年就一定深谙此道。从我观察到的现象来推测，在技术支持方面，此站提升空间还是挺大的，不仅是数据安全，我看到的挺多。
就说眼前可见的，不管是程序崩了还是操作系统崩了，连后手都木有，这不是一个所谓的团队该有的水准。

august 有些东西想想是好的，要真付诸实践，不是张口就来的。山外有山人外有人，BT团队运营那么多年，我不相信技术上没有考虑过你说的这些，毕竟不是运营团队的人都无法了解网站具体的真实情况。

一个月下来，看看中断多少次吧，你对你说的“BT团队运营那么多年，我不相信技术上没有考虑过你说的这些，毕竟不是运营团队的人都无法了解网站具体的真实情况”，你可还有这份自信？

我曾有个公司，就是做这些服务器、vps这类的，出售之前也是做到经济大省第二名了，你所说的人外有人这种话，在我面前就别说了，不合适。
外行当然了解不到，但没必要怀疑没人能做到。

我所说的方案，成本无非就是几十元，甚至如果有多个节点的话，互为主备，可能这两包烟钱都省下来了。实现的效果呢，最大限度降低离线时间，昨天还是前天，好像断了十几个小时吧，错误码是500，这是web自身问题。
更进一步，一个小小的脚本，就可以实现异常情况几秒内全自动切换，除去dns缓冲的时间，也就是几分钟内自动恢复，这在内行来说并不难。

我自己最近把物理机准备撤了，也买了个2t的vps这几天在迁移数据，5美元/月，不到40人民币，很贵么？

august 有些东西想想是好的，要真付诸实践，不是张口就来的。山外有山人外有人，BT团队运营那么多年，我不相信技术上没有考虑过你说的这些，毕竟不是运营团队的人都无法了解网站具体的真实情况。

也不用怀疑我说的全自动，早些年给一个客户做的网游方面的东西，也有某正规交易所的客户用了，全自动主备切换，秒级，不难的。
内行了呵呵，外行跑断腿，这就是差距