Gitlab官方对数据删除事件的说明
2017-02-04 11:51:44 
阿炯
事件回放：
GitLab.com 官方网站发布声明称由于其产品数据库问题导致的网站无法正常访问。据国外媒体报道称 Gitlab 网站疲惫的系统管理员深夜在进行数据库维护时，使用 rm -rf 删了300GB 生产环境数据。等到清醒过来紧急按下ctrl + c，只有4.5GB保留下来。然后恢复备份失败，网站已经宕了10个小时，现在还没恢复。目前可以确认的是 Gitlab 的数据备份是无效的。报告称此次数据丢失并非仓库的数据，而是仓库相关的 issue 以及合并请求操作。GitLab.com 号称有五重备份机制：常规备份(24小时做一次)、自动同步、LVM快照(24小时做一次)、Azure备份(只对 NFS 启用，对数据库无效)、S3备份。这次事故发生时，所有备份全部无效！为了纪念这个事件，已经有人提议，将2月1日定为“世界备份日”。恢复期间 Gitlab 在 Youtube 上直播了整个数据恢复过程。根据官方对整个事情的描述大概可以推断 Gitlab 使用的是故障发生前6个小时的备份数据。因此就算恢复了整个平台，这6个小时时间内的数据还是丢失了，目前官方已经确定了数据丢失的这个问题。
我们(GitLab.com)丢失了 6 小时的数据库数据(问题、合并请求、用户、评论、片段等)，Git / wiki 存储库和自托管安装不受影响。丢失生产数据是不可接受的，未来几天内，我们将会发布此次事故发生的原因及一系列措施的落实情况。
更新 18:14 UTC：GitLab.com 重新在线
截至撰写本文时，我们正在从 6 小时前的数据库备份中恢复数据。这意味着在 GitLab.com 再次生效的时候，17:20 UTC和 23:25 UTC 之间数据库丢失的任何数据都将恢复。
Git数据(存储库和维基)和 GitLab的自托管实例不受影响。
以下是本次事件的简要摘要，详细内容请查阅文档。
事件一：
在 2017/01/31 18:00 UTC ，我们检测到垃圾邮件发送者通过创建片段来攻击数据库，使其不稳定。然后，我们开始了解发生了什么问题进行故障排除，以及如何防范。
在2017/01/31 21:00 UTC，问题被升级导致在数据库上的写入锁定，这导致网站出现了一些时间段的宕机。
措施：
根据IP地址阻止了垃圾邮件发送者
删除了使用存储库作为某种形式的CDN 导致 47 000 个IP 使用同一个帐户登录(导致高DB负载)的用户
已移除用户发送垃圾邮件(通过创建代码段)
事件二：
在 2017/01/31 22:00 UTC， - 我们被分页，因为 DB 复制滞后太远，导致不能有效地阻止。发生这种情况是因为在辅助数据库没有及时处理写入。
措施：
尝试修复 db2，此时丢失数据约4 GB
db2.cluster 拒绝复制，/var/opt/gitlab/postgresql/data 擦拭以保证复制
db2.cluster 拒绝连接到 db1，max_wal_senders太低。此设置是用来限制数量 WAL (= replication)的客户端
团队成员1调整max_wal_senders 到 32上db1，重启 PostgreSQL 。PostgreSQL 因同时打开信号量太多而拒绝重启。
团队成员1调整 max_connections 8000 到 2000。PostgreSQL 重启成功(尽管8000已经使用了近一年)
db2.cluster 可以链接，但仍然复制失败，只是挂在那里没有执行任何的操作。今晚 23:00左右(当地时间)，团队成员1明确提到他要签字，并未想到会突然出现复制问题。
事件三：
在2017年1月31日23：00 左右 —团队成员1认为， pg_basebackup 拒绝执行是因为 PostgreSQL 的数据目录存在(尽管是空的)，于是决定删除该目录。经过一两秒钟，他注意到他运行在 db1.cluster.gitlab.com，而不是 db2.cluster.gitlab.com。
在2017年1月31日23:27 时，团队成员1 -终止删除操作，但为时已晚。大约 300 GB 左右的数据只剩下约4.5 GB，我们不得不把 GitLab.com 下线，并在 Twitter 上公布信息。
我们正在执行紧急数据库维护，https://t.co/r11UmmDLDE 将脱机。
GitLab.com 状态(@gitlabstatus)2017年1月31日。
遇到的问题
默认情况下，LVM 快照每 24 小时采取一次。为了数据库的工作负载平衡，团队成员 1 在停电前 6小时手动操作过。
定期备份似乎也只能每24小时执行一次，虽然团队成员1目前仍未能找出它们的存储位置。团队成员2表示 ，这些似乎没有奏效，产生的文件大小只有几个字节。
团队成员3：看起来 pg_dump 可能会失败，因为 PostgreSQL 的 9.2 二进制文件正在运行，而不是 9.6 的二进制文件。这是因为 omnibus 只使用 Pg 9.6 ，如果 data / PG_VERSION 设置为 9.6，但在 workers 上这个文件不存在。因此，它默认为 9.2，静默失败。因此没有做出 SQL 转储。Fog gem 可能已清理旧备份。
为Azure 服务器启用 Azure 中的磁盘快照，而不是 DB 服务器。
同步过程在 Webhooks 数据同步到暂存后删除。我们只能从过去24小时的定期备份中提取内容，否则将丢失
复制过程是超级脆弱，容易出错，依赖少数随机 shell 脚本并记录
我们的备份到 S3 显然也不运行：bucket 是空的
因此，换句话说，部署的 5 个备份/复制技术中没有一个可靠地运行或设置。我们最终还原了6 小时前的备份。
pg_basebackup 将等待主机启动复制进程，据另一个生产工程师称，这可能需要 10 分钟。这可能导致进程被卡住。使用 “strace” 运行进程没有提供的有用信息。
所以换句话说，在部署的5套备份/复制方法中，没有一套在可靠运行或当初设置正确。此话一出，网上炸开了锅。为了概述所犯的错误，这家初创公司坦率地作了如下详述：
LVM快照在默认情况下每24小时做一次。在故障发生前大概6小时，YP正好手动运行了一次。
常规备份似乎也是每24小时做一次，不过YP还未能查清楚它们存储在何处。据JN声称，这些似乎未奏效，只生成了几个字节大小的文件。
SH：pg_dump似乎失效了，原因是运行的是PostgreSQL 9.2二进制代码，而不是9.6二进制代码。之所以会出现这种情况，是由于如果data/PG_VERSION被设成9.6，omnibus只使用Pg 9.6，但是在worker节点上，该文件并不存在。因而，它在默认情况下运行9.2，悄然失效。因而没有SQL转储出现。Fog gem可能清除掉了早些时候的备份。
已为NFS服务器启用了Azure中的磁盘快照，但是没有为数据库服务器启用Azure中的磁盘快照。
一旦将数据同步到试运行环境，同步过程就消除Web勾子(webhook)。除非我们可以在过去的24小时内从常规备份中获取这些数据，否则它们将丢失殆尽。
复制程序很不可靠，容易出错，依赖几个随机性的外壳脚本，而且缺少完备的说明文档。
我们备份到S3的内容显然也没有奏效：存储桶(bucket)空空如也。
恢复
我们正在使用临时数据库中的数据库备份来立即恢复。
我们不小心删除了生产数据，可能必须从备份中还原。谷歌文档与现场笔记 https://t.co/EVRbHzYlk8
GitLab.com 状态(@gitlabstatus)2017年2月1日
2017年2月1日00:36 -备份 db1.staging.gitlab.com 数据
2017年2月1日00:55 -在 db1.cluster.gitlab.com 安装 db1.staging.gitlab.com
从分段复制数据 /var/opt/gitlab/postgresql/data/ 到生成 /var/opt/gitlab/postgresql/data/
2017年2月1日01:05 - nfs-share01 服务器 征用临时存储/var/opt/gitlab/db-meltdown
2017年2月1日01:18 - 复制剩余的生成数据，包括pg_xlog，升级为20170131-db-meltodwn-backup.tar.gz
此外，我们要感谢在Twitter 和其他渠道通过#hugops获得的惊人支持。
参考来源：GitLab.com Database Incident
点击这里可以看到德哥对些事件的点评，在酷壳上也有对此事的分析。
本文源自：互联网
或因驱动器故障，FreeDesktop.org GitLab 持续崩溃
2022年6月上旬消息，由于 FreeDesktop.org 的 GitLab 托管服务的持续崩溃，围绕 Mesa、X.Org Server 和数十个其他开源项目的集中式开发一直处于停滞状态。其 GitLab 托管着 Mesa、X.Org、Wayland 和其他开源代码存储库，例如 LibreOffice 和 GStreamer。此外它还为参与这些项目的开发人员托管着个人的开发仓库，并通过 GitLab 合并请求、CI 和协调上游的开发。
大约在 6 月 12 日的中午 12 点开始出现 402 ，继而转向 404 ，且在过去的 12 小时内持续关闭，官方没有公布计划完成修复的具体时间点。据外媒 phoronix 介绍，FreeDesktop.org 服务受到影响是因为为其供电的两个固态驱动器损坏了，但官方尚未公布具体原因。用户可以通过 #freedesktop 的 IRC 频道查看关于该问题的实时讨论和最新情况。FreeDesktop.org 的管理员在过去几个小时内一直在努力尝试恢复集群，但到目前为止无济于事。
GitLab.com 官方网站发布声明称由于其产品数据库问题导致的网站无法正常访问。据国外媒体报道称 Gitlab 网站疲惫的系统管理员深夜在进行数据库维护时，使用 rm -rf 删了300GB 生产环境数据。等到清醒过来紧急按下ctrl + c，只有4.5GB保留下来。然后恢复备份失败，网站已经宕了10个小时，现在还没恢复。目前可以确认的是 Gitlab 的数据备份是无效的。报告称此次数据丢失并非仓库的数据，而是仓库相关的 issue 以及合并请求操作。GitLab.com 号称有五重备份机制：常规备份(24小时做一次)、自动同步、LVM快照(24小时做一次)、Azure备份(只对 NFS 启用，对数据库无效)、S3备份。这次事故发生时，所有备份全部无效！为了纪念这个事件，已经有人提议，将2月1日定为“世界备份日”。恢复期间 Gitlab 在 Youtube 上直播了整个数据恢复过程。根据官方对整个事情的描述大概可以推断 Gitlab 使用的是故障发生前6个小时的备份数据。因此就算恢复了整个平台，这6个小时时间内的数据还是丢失了，目前官方已经确定了数据丢失的这个问题。
我们(GitLab.com)丢失了 6 小时的数据库数据(问题、合并请求、用户、评论、片段等)，Git / wiki 存储库和自托管安装不受影响。丢失生产数据是不可接受的，未来几天内，我们将会发布此次事故发生的原因及一系列措施的落实情况。
更新 18:14 UTC：GitLab.com 重新在线
截至撰写本文时，我们正在从 6 小时前的数据库备份中恢复数据。这意味着在 GitLab.com 再次生效的时候，17:20 UTC和 23:25 UTC 之间数据库丢失的任何数据都将恢复。
Git数据(存储库和维基)和 GitLab的自托管实例不受影响。
以下是本次事件的简要摘要，详细内容请查阅文档。
事件一：
在 2017/01/31 18:00 UTC ，我们检测到垃圾邮件发送者通过创建片段来攻击数据库，使其不稳定。然后，我们开始了解发生了什么问题进行故障排除，以及如何防范。
在2017/01/31 21:00 UTC，问题被升级导致在数据库上的写入锁定，这导致网站出现了一些时间段的宕机。
措施：
根据IP地址阻止了垃圾邮件发送者
删除了使用存储库作为某种形式的CDN 导致 47 000 个IP 使用同一个帐户登录(导致高DB负载)的用户
已移除用户发送垃圾邮件(通过创建代码段)
事件二：
在 2017/01/31 22:00 UTC， - 我们被分页，因为 DB 复制滞后太远，导致不能有效地阻止。发生这种情况是因为在辅助数据库没有及时处理写入。
措施：
尝试修复 db2，此时丢失数据约4 GB
db2.cluster 拒绝复制，/var/opt/gitlab/postgresql/data 擦拭以保证复制
db2.cluster 拒绝连接到 db1，max_wal_senders太低。此设置是用来限制数量 WAL (= replication)的客户端
团队成员1调整max_wal_senders 到 32上db1，重启 PostgreSQL 。PostgreSQL 因同时打开信号量太多而拒绝重启。
团队成员1调整 max_connections 8000 到 2000。PostgreSQL 重启成功(尽管8000已经使用了近一年)
db2.cluster 可以链接，但仍然复制失败，只是挂在那里没有执行任何的操作。今晚 23:00左右(当地时间)，团队成员1明确提到他要签字，并未想到会突然出现复制问题。
事件三：
在2017年1月31日23：00 左右 —团队成员1认为， pg_basebackup 拒绝执行是因为 PostgreSQL 的数据目录存在(尽管是空的)，于是决定删除该目录。经过一两秒钟，他注意到他运行在 db1.cluster.gitlab.com，而不是 db2.cluster.gitlab.com。
在2017年1月31日23:27 时，团队成员1 -终止删除操作，但为时已晚。大约 300 GB 左右的数据只剩下约4.5 GB，我们不得不把 GitLab.com 下线，并在 Twitter 上公布信息。
我们正在执行紧急数据库维护，https://t.co/r11UmmDLDE 将脱机。
GitLab.com 状态(@gitlabstatus)2017年1月31日。
遇到的问题
默认情况下，LVM 快照每 24 小时采取一次。为了数据库的工作负载平衡，团队成员 1 在停电前 6小时手动操作过。
定期备份似乎也只能每24小时执行一次，虽然团队成员1目前仍未能找出它们的存储位置。团队成员2表示 ，这些似乎没有奏效，产生的文件大小只有几个字节。
团队成员3：看起来 pg_dump 可能会失败，因为 PostgreSQL 的 9.2 二进制文件正在运行，而不是 9.6 的二进制文件。这是因为 omnibus 只使用 Pg 9.6 ，如果 data / PG_VERSION 设置为 9.6，但在 workers 上这个文件不存在。因此，它默认为 9.2，静默失败。因此没有做出 SQL 转储。Fog gem 可能已清理旧备份。
为Azure 服务器启用 Azure 中的磁盘快照，而不是 DB 服务器。
同步过程在 Webhooks 数据同步到暂存后删除。我们只能从过去24小时的定期备份中提取内容，否则将丢失
复制过程是超级脆弱，容易出错，依赖少数随机 shell 脚本并记录
我们的备份到 S3 显然也不运行：bucket 是空的
因此，换句话说，部署的 5 个备份/复制技术中没有一个可靠地运行或设置。我们最终还原了6 小时前的备份。
pg_basebackup 将等待主机启动复制进程，据另一个生产工程师称，这可能需要 10 分钟。这可能导致进程被卡住。使用 “strace” 运行进程没有提供的有用信息。
所以换句话说，在部署的5套备份/复制方法中，没有一套在可靠运行或当初设置正确。此话一出，网上炸开了锅。为了概述所犯的错误，这家初创公司坦率地作了如下详述：
LVM快照在默认情况下每24小时做一次。在故障发生前大概6小时，YP正好手动运行了一次。
常规备份似乎也是每24小时做一次，不过YP还未能查清楚它们存储在何处。据JN声称，这些似乎未奏效，只生成了几个字节大小的文件。
SH：pg_dump似乎失效了，原因是运行的是PostgreSQL 9.2二进制代码，而不是9.6二进制代码。之所以会出现这种情况，是由于如果data/PG_VERSION被设成9.6，omnibus只使用Pg 9.6，但是在worker节点上，该文件并不存在。因而，它在默认情况下运行9.2，悄然失效。因而没有SQL转储出现。Fog gem可能清除掉了早些时候的备份。
已为NFS服务器启用了Azure中的磁盘快照，但是没有为数据库服务器启用Azure中的磁盘快照。
一旦将数据同步到试运行环境，同步过程就消除Web勾子(webhook)。除非我们可以在过去的24小时内从常规备份中获取这些数据，否则它们将丢失殆尽。
复制程序很不可靠，容易出错，依赖几个随机性的外壳脚本，而且缺少完备的说明文档。
我们备份到S3的内容显然也没有奏效：存储桶(bucket)空空如也。
恢复
我们正在使用临时数据库中的数据库备份来立即恢复。
我们不小心删除了生产数据，可能必须从备份中还原。谷歌文档与现场笔记 https://t.co/EVRbHzYlk8
GitLab.com 状态(@gitlabstatus)2017年2月1日
2017年2月1日00:36 -备份 db1.staging.gitlab.com 数据
2017年2月1日00:55 -在 db1.cluster.gitlab.com 安装 db1.staging.gitlab.com
从分段复制数据 /var/opt/gitlab/postgresql/data/ 到生成 /var/opt/gitlab/postgresql/data/
2017年2月1日01:05 - nfs-share01 服务器 征用临时存储/var/opt/gitlab/db-meltdown
2017年2月1日01:18 - 复制剩余的生成数据，包括pg_xlog，升级为20170131-db-meltodwn-backup.tar.gz
此外，我们要感谢在Twitter 和其他渠道通过#hugops获得的惊人支持。
参考来源：GitLab.com Database Incident
点击这里可以看到德哥对些事件的点评，在酷壳上也有对此事的分析。
本文源自：互联网
或因驱动器故障，FreeDesktop.org GitLab 持续崩溃
2022年6月上旬消息，由于 FreeDesktop.org 的 GitLab 托管服务的持续崩溃，围绕 Mesa、X.Org Server 和数十个其他开源项目的集中式开发一直处于停滞状态。其 GitLab 托管着 Mesa、X.Org、Wayland 和其他开源代码存储库，例如 LibreOffice 和 GStreamer。此外它还为参与这些项目的开发人员托管着个人的开发仓库，并通过 GitLab 合并请求、CI 和协调上游的开发。
大约在 6 月 12 日的中午 12 点开始出现 402 ，继而转向 404 ，且在过去的 12 小时内持续关闭，官方没有公布计划完成修复的具体时间点。据外媒 phoronix 介绍，FreeDesktop.org 服务受到影响是因为为其供电的两个固态驱动器损坏了，但官方尚未公布具体原因。用户可以通过 #freedesktop 的 IRC 频道查看关于该问题的实时讨论和最新情况。FreeDesktop.org 的管理员在过去几个小时内一直在努力尝试恢复集群，但到目前为止无济于事。