# 一位工程师删除了GitLab的生产数据库。300 GB。

Published: 2026-09-10

2017年1月31日，世界标准时间23:27：一位GitLab工程师在熬夜修复一个损坏的副本时，不小心删除了db1而非db2上的PostgreSQL数据目录。db1是主数据库。GitLab.com大约300 GB的数据库在一两秒内消失了，而且五个备份和复制机制都失效了。事后分析：从垃圾邮件高峰到错误主机名的时间线，pg\_basebackup为何看似卡住，pg\_dump为何一直静默失败（9.2二进制文件在9.6数据库上，失败邮件被DMARC退回），从6小时前暂存快照恢复的18小时过程在YouTube上直播，以及谁应该真正承担责任。对响应的评价：SHIP IT。

Canonical: https://thedailydiff.dev/zh-CN/video/2026-09-10-gitlab-rm-rf/

## 本视频涵盖的内容

- 2017年1月31日：在主数据库的数据目录上执行rm -Rvf；约300 GB被删除，留下4.5 GB
- 5个备份全部失败：S3桶为空（pg\_dump版本不匹配），数据库没有Azure快照，副本被清除，每日LVM复制没有Webhooks
- 2月1日，世界标准时间18:00：GitLab.com从6小时前的手动快照恢复；实时文档、直播、附带修复列表的无责事后分析

## 翻译的文字记录

译自英文原版旁白。可用音频和字幕由 YouTube 控制。

0:00 GitLab的一名工程师在错误的数据库服务器上运行了 rm -rf， 然后 GitLab.com 的三百吉字节数据在一两秒内消失了， 这大约是读取一个主机名所需的时间。 2017年1月31日，晚上11:27， 世界标准时间。GitLab 发推称其不小心删除了生产数据， 向互联网公开了事故记录，并在 YouTube 上直播了恢复过程， 这是该平台第二热门的直播。 第二天，书面声明：五种备份技术中，

0:25 没有一种能可靠运行。 它是如何发生的，为什么会发生，以及谁应该真正承担责任。 这里是 The Daily Diff，事后分析。 下午5:20：一名工程师制作了生产快照， 以测试暂存环境中的负载均衡器。 晚上7点：垃圾邮件攻击数据库，以及一个硬删除GitLab员工的作业， 该员工因被举报滥用行为。 晚上11点：副本落后太多，以至于主数据库已经丢弃了

0:48 它所需的日志；唯一的修复方法是清除副本并重新复制主数据库。 pg\_basebackup 挂起，没有输出。 它实际上是在静默等待主数据库；没有人知道这一点， 操作手册也没有说明。 这位工程师本打算在11点下班，他认为空数据目录是问题所在，并将其删除。 他认为空数据目录是问题所在并将其删除。 在 db1 上。主数据库。 一两秒后他注意到了；大约三百吉字节的数据中，

1:11 剩下4.5 GB。备份。 第一：pg\_dump 到 S3，每日执行。 桶是空的。 cron 任务在一个没有数据库的应用服务器上运行，所以软件包选择了 用于 9.6 数据库的 PostgreSQL 9.2 二进制文件，失败，并发送邮件 失败通知，由于缺少 DMARC 而被退回。 第二：Azure 磁盘快照，为文件服务器启用， 而不是数据库。

1:32 第三：副本，一小时前被故意清除。 第四：每日快照，24小时前，所有 webhook 被 暂存同步剥离。第五：下午5:20的手动快照，用于不相关的测试。 这个快照成功了。 恢复意味着以每秒六十兆比特的速度，通过 Azure 的廉价存储将暂存磁盘复制回生产环境： 需要十八个小时。 GitLab.com 于2月1日晚上6点恢复。 世界标准时间，数据落后六小时。

1:58 git blame：两个主机名仅相差一个字符，以及五个从未有人 恢复过的备份系统。 不是工程师的错。 由首席执行官签署的事后报告让他匿名， 将生产提示符设为红色，并为数据持久性指定了负责人， 因为在此之前它没有负责人。 影响范围：停机十八小时，数据丢失六小时， 大约五千个项目，五千条评论，

2:18 七百个新用户，以及五千人看着进度条。 Hacker News 给这份实时文档打了1,162分，并引用了其中一句话 回复他们：五个备份中，没有一个可用。 裁决，事后分析：对响应的评价是 SHIP IT。 他们公开处理了事故，归咎于流程，并发布了带有问题编号的修复列表。 并发布了带有问题编号的修复列表。 周一行动：恢复备份。 如果你从未恢复过它，你就是没有备份。

2:42 把你仍然不被允许谈论的事故发给我， 在评论区，或发送至 the daily diff dot dev。 这就是今天的 The Daily Diff。 我是 Axrisi 的 Niko。 负责任地合并。

## 来源

- [GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — about.gitlab.com
- [GitLab, "GitLab.com database incident" (Feb 1, 2017)](https://about.gitlab.com/blog/gitlab-dot-com-database-incident/) — about.gitlab.com
- [@gitlabstatus, "We accidentally deleted production data…"](https://twitter.com/gitlabstatus/status/826591961444384768) — twitter.com
- [@gitlabstatus, emergency maintenance notice](https://twitter.com/gitlabstatus/status/826572933304827904) — twitter.com
- [Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)](https://news.ycombinator.com/item?id=13537052) — news.ycombinator.com
- [Hacker News, the postmortem thread (377 points)](https://news.ycombinator.com/item?id=13619714) — news.ycombinator.com