虽然还在春节假期，但IT人的微博和朋友圈，在昨天（2月1日），因为Gitlab的数据丢失事件，炸开了锅。数据丢失或业务宕机事件已经不止一次两次出现，但鉴于此次事件主角的特殊身份，仍然受到极大的关注，我们一起来回顾下这次事件在各大媒体的传播路径。

关于GitLab（为什么说身份特殊）：

GitLab 创办于2014年，总部位于美国旧金山。GitLab 的平台能够实现git仓库管理、代码审查、问题跟踪、集成开发环境、活动信息流和WIkI等功能。此外，平台配合GitLab CI 还能够实现更加简单的持续集成和自动部署。

GitLab孵化于YC，已服务于10万＋公司／组织，并在2016年9月获得来自August Capital的2000万美金的B论融资，是硅谷一家明星创业公司。

公司官网：www.gitlab.com

2月1日10点（美东时间：2017/01/31 18:00）

媒介：GitLab官网（Github恢复上线后，官网整理发布于其Bolg）

GitLab发现数据库受到垃圾邮件的攻击，导致服务器出现不稳定的情况。技术人员开始排查和解决问题。

2月1日13点（美东时间：2017/01/31 21:00）

媒介：GitLab官网（Github恢复上线后，官网整理发布于其Bolg）

GitLab技术人员对数据库进行了升级，升级导致了数据库的写入被锁定lockup，从而使得网站出现了一些时间段的宕机。

2月1日14点（美东时间：2017/01/31 22:00）

媒介：GitLab官网（Github恢复上线后，官网整理发布于其Bolg）

我们被分页，因为 DB 复制滞后太远，导致不能有效地阻止。发生这种情况是因为在辅助数据库没有及时处理写入。

2月1日15:27点（美东时间：2017/01/31 23:27）

媒介：GitLab官网（Github恢复上线后，官网整理发布于其Bolg）

GitLab技术人员怀疑 pg_basebackup 失效是因为PostgreSQL 数据库目录（虽然是个空目录）的存在，所以打算删除该目录，但误将删除指令运行在了db1.cluster.gitlab.com上，而非db2.cluster.gitlab.com，从而导致了大量数据的丢失。（300GB只剩下4.5 GB）

2月1日 16:00左右，Twitter

GitLab将GitLab.com下线，并在Twitter上发布相关事件信息和进展。

这里的7:28 AM, 8:08AM, 8:44AM应当是那位荷兰哥们儿所处的时区，大致对应北京时间的2月1日 16:00左右。

2月1日15:30，微博

微博帐号为ruanrf的用户发微博提到“GitLab.com这次麻烦了，数据库维护时，rm -rf 删了300GB 生产环境数据。等到清醒过来紧急按下ctrl + c，只有4.5GB保留下来。然后恢复备份失败，网站已经宕了10个小时，现在还没恢复。”并提供了报道该事件的国外网站：https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/?mt=1485933661486。微博仍然是个人爆料的首选媒体渠道。

2月1日16:43，技术社区

开源中国社区官网成为国内首家关注了GitLab误删数据事件的媒体，在其官网发布《Gitlab.com 误删数据，备份恢复失败已宕机 10 小时》。

2月1日16:43-18:00，微信公众号

云头条微信公众号转发了开源中国社区官网的新闻。至此，该事件已从微博和开源中国官网传播至IT类微信公众号。

2月1日18:03，微信公众号

云头条微信公众号发布了《GitLab.com崩溃，rm -rf 删了300GB数据；要命的是，备份偏偏失效》，重点描述了事件最新进展以及网友们关注的为何5套备份／复制方法均失效的原因，并转引了一些微博用户的实时评论。

2月1日18:10，微博

英方股份蓝微跟进事件，转发了ruanyf的微博，并进行了评论。

2月1日19:57，微博

英方股份蓝微继续跟进事件，发布了《rm -rf 引发的那些血案》，引用了英国发生的一起同是由rm -rf 引起的误删除事件，并给出了一些应对方案。

2月1日21:00左右，YouTube

GitLab在Youtube在线直播整个数据恢复过程，并在Twitter上同步恢复进程，心够大。https://www.youtube.com/watch?v=nc0hPGerSd4

2月1日22:30左右

B站开始转播GitLab数据恢复过程，国内群众开始在线围观，可惜没有字幕翻译。http://live.bilibili.com/19398

2月1日22:07，微信公众号

Oracle微信公众号发布了《五重备份无一生效，还有哪些 rm- rf和GitLab类似的忧伤？》，列举了多类因一系列rm操作引起的误删情形，并分享了防范频发的数据误删除操作在内的6则DBA生存警示。

2月1日22:50，微信公众号

老叶茶馆微信公众号发布了《又搞飞机了，号称有五重备份的GitLab居然也歇了》，认为对备份机制过分信任，却可能没有可靠的备份恢复测试及验证机制，是非常危险的行为。

2月1日22:58，微信公众号

程序员那些事儿微信公众号发布了《rm -rf 惨案：GitLab误删生产数据！》，重点描述了事件最新进展和来自Solidot、维基、Twitter、微博的一些网友评论。

2月1日23:09，微信公众号

DBAplus社群微信公众号发布了《99%数据被删除，5类备份全部失效怎么破》，重点描述了在技术层面、运维层面、管理层面从此次事件中可以得到哪些教训。

2月1日23:56，知乎

知乎上创建了《如何评价 2017 年 2 月 1 日 GitLab 数据库被误删？》，1091人关注，52个回答。

2月2日，各大媒体大范围跟进

大量网站媒体，IT 类微信公众号对事件进行大量的跟进和深入报道。

2月2日凌晨一两点左右

GitLab服务已经恢复，但只恢复至事故发生前6小时的状态，这6小时内的数据还是丢失了，官网已经确认了数据丢失的问题。

写在最后

从国外媒体微博爆料这次事件，个人微博转引，国内开源社区关注，到几家对事件性新闻较敏感的IT类微信公众号和蓝微的跟进，再到其他IT类媒体的深入报道和知乎的传播，使得事件虽然发生在春节期间，但传播量和关注度依然爆棚，媒体的敬业让人称赞，更让人称赞的还有GitLab透明的故障处理过程：在Twitter公开事件进展，在YouTube上直播数据恢复进程，上线后，在官网公布事件始末，没有任何隐瞒，是一次非常成功的公关处理。

英方作为一家专注于容灾高可用的科技公司，也一直在关注各类数据丢失或业务宕机事件，先进的容灾技术、严谨的实施和在政府、金融、医疗、能源、互联网等领域的容灾实践已经帮助千万家企业提供相关解决方案，帮助其减少数据丢失的风险，降低业务宕机的几率。
I 延伸阅读：

网游行业服务器故障盘点；