Gitlab 网站疲惫的系统管理员深夜在进行数据库维护时，使用 rm -rf 删了300GB 生产环境数据。等到清醒过来紧急按下ctrl + c，只有4.5GB保留下来。然后恢复备份失败，网站已经宕了10个小时，现在还没恢复。
GitLab.com 官方网站发布声明称由于其产品数据库问题导致的网站无法正常访问。据国外媒体报道称 Gitlab 网站疲惫的系统管理员深夜在进行数据库维护时，使用 rm -rf 删了300GB 生产环境数据。等到清醒过来紧急按下ctrl + c，只有4.5GB保留下来。然后恢复备份失败，网站已经宕了10个小时，现在还没恢复。
目前可以确认的是 Gitlab 的数据备份是无效的。报告称此次数据丢失并非仓库的数据，而是仓库相关的 issue 以及合并请求操作。
GitLab.com 号称有五重备份机制：常规备份（24小时做一次）、自动同步、LVM快照（24小时做一次）、Azure备份（只对 NFS 启用，对数据库无效）、S3备份。这次事故发生时，所有备份全部无效！为了纪念这个事件，已经有人提议，将2月1日定为“世界备份日”
《炉石传说》游戏数据库回档事件刚过去几天，GitLab又来凑热闹了
今天下午开始，朋友圈被GitLab误删数据事件给刷爆了。截止发稿时还是离线维护状态。
中国农历春节前才刚刚出了《炉石传说》游戏数据库回档事件（猜测是因为认为误操作导致数据丢失并且备份也失效）。农历春节都还没过去，GitLab也来给大家增加谈资了。
先来看下官方发布的消息：
不过好在这次误删除的数据不是最关键的代码仓库数据，也算是不幸中的万幸。
GitLab号称有五重备份：
每24小时LVM快照备份；
每24小时常规备份；
S3备份；
应该是调用了pg_dump的脚本自动备份；
Azure备份（只对 NFS 启用，非数据库备份）；
从披露的消息并没看到他们如何确认备份数据的有效性，这也是最可怕的地方：对备份机制过分信任，却可能没有可靠的备份恢复测试及验证机制，这是非常危险的行为。
备份文件务必进行恢复测试。此外，重要操作命令一定要想清楚、看清楚了再回车确认，发生事故时再怨天尤人，怪老板没给加薪、没发过年红包、过度加班疲劳等都是扯淡的理由，还是自觉面壁去吧~~
和服务器打交道的都要谨慎，这不仅仅是DBA该具备的素质，也不用搞什么“世界备份日”，最重要的是做好备份、并想进一切手段避免误操作，时刻保持敬畏之心。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
