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

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 之家毕竟本身就带着一些额外的属性，所以有些时候为了能让站点继续存在下去，或许选择「数据丢失」是最好的方案。

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