对养猫君对葱爆的分析的分析

@爱狗却养猫 <#155212>

首先我不认为钢铁雄心（HOI）进行的攻击是造成品葱数据丢失的原因。品葱丢失了大半年的数据，最大的可能性是服务器出现故障造成数据库损坏，责任一半在于不可抗力，一半在于品葱站长长期不自行备份数据。HOI攻击的效果是增加品葱的管理负担，占用其私信空间，但品葱大故障恐怕不能甩锅/归功于ta。

虽然养猫君的个人数字安全防护做得很完善，但他并非IT从业人士，对于架服务器办网站方面的技术分析，看的时候要在心里打个折扣。

首先，新品葱网站是云服务器而不是物理服务器（100%确定），CF之前被别人记录过IP。

• 2047的服务器在专人托管的电信机房里，很多操作没有云服务方便，uptime也没有云服务高，但是硬件配置可以随时加减，且不用担心被服务商删封（下面会详细讲）。从建站到现在2047发生过好几次宕机事故，除了第一次因为物理问题损失10天内容（且绝大部分由本人配合网友修复）以外，中间好几次都是利用备份数据直接复原，包括虚拟机都换了几次，但一般用户除了服务临时中断之外基本不会有什么感觉。物理服务器的好处就在这里：**即使遇到操作系统无法启动的严重故障，也可以打电话到机房，让工程师把硬盘拔下来、数据拷出来。**而云服务器一旦无法启动，如果跟服务商关系不好，就只能听天由命了。

  不过物理服务器并非2047的专利，创世之初，所有网站都是物理服务器的，例如acfun最开始建站的时候就是一台机械硬盘的家用PC~

• 云服务器备份麻烦，很有可能是站长这么久不备份的原因之一（2047是每10分钟全站备份一次），因为云服务器在云上，从云上把整个数据库拖下来是需要时间和带宽的（自动备份要加钱，下面会提到），以及云上没有windows（windows也要加钱），很多操作很麻烦，而品葱站长水平又低又吝啬又怕麻烦是众所周知的。

• 最早新品葱是有每周数据备份的，但公开的都是一个月前的备份，因为站长担心提供最近的备份会导致用户被社工。2020年4-7月新品葱出现站务危机，后来站长就越来越少公开备份了，估计是怕被人拿来搞破坏。in comparison，2047最近一次公布的备份是8月24号的https://github.com/thphd/2047/releases/tag/0.0.1。

既然是云服务器，就不得不提云服务器最大的优点：几乎不会故障。

• 云服务器的CPU、内存不是实体CPU、内存，而是带有冗余的虚拟CPU、内存。实体服务器关机以前，是可以把虚拟机无缝迁移到其他实体服务器上继续运行的。所以云服务器可以实现大半年不关机。

• 云服务器的硬盘不是实体硬盘，而是带有冗余校验的虚拟硬盘，基本上可以说只要机房不着火不进水，很难把数据弄丢、搞坏，所以云服务器的数据可以大半年不备份。而物理服务器必须时刻备份，否则硬盘挂掉就啥都没了，2047每10分钟备份一次正是因为是这个原因。

所以**“最大的可能性是服务器出现故障造成数据库损坏”**是不正确的。

• 但是云服务器有一种情况会把数据搞丢，那就是站长忘了给服务商续费，或者因为违反美国或者日本法律或者服务协议，被服务商终止服务，然后服务商把硬盘删掉了，因为是虚拟硬盘所以跟删文件一样方便，而且删掉之后很难找回来。品葱站长为了匿名，选择的是没有KYC的服务商，网友捐款又被他自己贪掉了（不然不会变成现在这样，要知道Vultr的付费随时自动备份功能只需多交20%费用，而品葱站长收了几千美金捐款外加法轮功广告费），所以现在出现这种问题，服务商大概率是不会开后门的。

• 2047是物理服务器，想删2047的数据，要么技术高深黑进来把所有备份删掉，要么一把火把机房烧了。而且就算机房烧了，github上也还有数据，使用GPG登陆的朋友也仍然可以登陆。

了解了云服务器和物理服务器的区别之后，我们再来看葱爆的案子：

• 钢铁雄心（HOI）给品葱站长喂紫薯布丁（发垃圾消息），是一种DoS攻击，由于品葱服务器的磁盘大小是有限的（而且非常有限），随着布丁越喂越多，磁盘剩余空间会越来越小，直到塞满，数据库无法写入。

• 数据库无法写入也就无法读出（因为读出的过程必然伴随写入，例如你看帖子会增加阅读数），网站当然就无法工作了。这时如果品葱站长重启服务器，因为开机过程也是需要写入磁盘的，磁盘空间不足可能导致开机卡死。而云服务器无法开机就连不上，也就无法进行远程操作，不像物理服务器可以直接拔硬盘读数据。这时如果站长急中生智，作出一些奇妙的误操作，就可能导致虚拟硬盘被删除。当然，也可能品葱服务器空间本来就不足了，HOI喂的补丁成了骆驼背上的最后一根稻草。

• MySQL遇到磁盘已满的情况，并不会返回DISK_FULL错误并拒绝服务，而会直接当场卡死，除非非常了解mysql工作原理，否则只能强行重启：https://dev.mysql.com/doc/refman/8.0/en/full-disk.html

• 所以另一种情况是，品葱站长强行重启了服务器，开启了数据库，数据库尝试从上一次强行重启的地方开始恢复。由于几乎所有数据库都依赖某种b+tree，而b+tree最流行的实现是leveldb（myrocks），leveldb极度依赖底层磁盘的顺序写入特性，如果底层磁盘（这个例子中是虚拟磁盘）不完全是顺序写入的（例如为了性能开启写入缓存），那么强行重启就会导致丢失最近写入的几个ldb文件，而leveldb在这种故障模式下完全无法recover（因为作者假定磁盘是强顺序写入的），使得强行重启有一定几率会导致丢失自上次启动数据库以来的所有数据。刚才已经说过，品葱服务器很可能是大半年不重启的。当然品葱的MySQL用的是什么后端我不清楚，但磁盘已满导致软件错误（而不是硬件故障）在IT界是非常常见的，运维老司机的法宝就是在每个磁盘放一个8G的空文件，如果任何原因导致磁盘已满，删掉文件就可以让服务瞬间恢复正常，然后再去花时间进一步排除问题。

所以说**“品葱大故障恐怕不能甩锅/归功于HOI”**，我觉得不合适，就目前掌握的证据，结合相关专业知识来看，我认为有30%可能性是HOI导致的，余下责任则归于品葱站长个人弃坑。当然HOI可能说谎，但同样的鹿儿也可能说谎，不应轻易下结论。