1. 聚能聊>
  2. 话题详情

从Gitlab数据库被删无法完全恢复看数据备份的重要性和操作性

upload_ueditor_image_20170201_1485959227657021188

搞数据库的各位,估计都看过这个图,以自嘲自己的 DBA 身份。不过,2月1日(北京时间)大年初五,GitLab 就搞了个大新闻,删了数据库!

GitLab_logo

2月1日著名的数据的代码托管网站 Gitlab 的一个工程师在长期疲劳操作时,不慎误删数据,等工程师反应过来,500G 生产环境数据被删的只剩 4.5G 。不过这个小哥倒是没有跑路,而是选择了直播回复数据。在经过近 7 个小时后的努力,数据最终恢复成功,但是依然是丢失了 6 个小时的数据。

好在代码数据没有丢失,丢失的是 PR 和 Issue 的讨论信息,对于众多码农,可能会选择使用 GitLab 来自建版本控制或使用 github 提供的企业服务。

说归说,不是 Gitlab 的核心人物,我们不讨论他们的发展问题。我们来聊一聊 gitlab 这次事故背后的一些问题。

Gitlab 由于是做公共服务。所以在备份这件事上还是比较看重的,GitLab.com 号称有五重备份机制:常规备份(24小时做一次)、自动同步、LVM快照(24小时做一次)、Azure备份(只对 NFS 启用,对数据库无效)、S3备份。这次事故发生时,所有备份全部无效!

幸好还有一个“也许可行”的六个小时前的备份,数据成功的被恢复回来。

针对这次事故,Gitlab 也给出了自己的解决方案和未来针对备份的ToDo list

  1. 更改服务器终端的颜色来区分生产环境(红色)、测试环境(黄色)。
  2. 定期检查数据库备份的目录,查看备份的数据是否成功备份。
  3. 添加备份提醒,定期检查S3 Bucket的大小,如果备份大小小于数据库大小、备份频率超过设定的时间,就发送警告。
  4. 调整 PostgreSQL 的配置,线上环境中 PGSQL 的连接数过大,导致备份失效,从8000降到2000,或者使用数据库连接池。
    阿里云数据库专家德歌也发表了《Gitlab从删库到恢复》的博文,点此了解>>

那么在学习完了 Gitlab 的备份心得后,不知道你有没有自己的备份心得?平时,你是如何在服务器上进行备份的呢?你又如何来保证数据安全呢?

参与话题

奖品区域 活动规则 已 结束

  • 奖品一

    淘公仔 x 4

  • 奖品二

    优酷VIP季卡 x 1

  • 奖品三

    定制笔记本 x 1

91个回答

6

傻仙人 已获得淘公仔 复制链接去分享

GitLab 真是挺诚实的。不过如果合理操作,是可以恢复百分之九十以上的数据的。之前下厨房也删过一次磁盘,如果有人还记得的话。

做运维,宁可冗余,不可轻易删除。写程序操作数据库也是,加个标记位 deleted 来标记删除,防止哪天操作错了,数据没了。

西秦说云 回复

点赞一句!宁可冗余,不可轻易删除!

mythlee 回复

宁可冗余,不可轻易删除! 赞

评论
2

szm. 已获得定制笔记本 复制链接去分享

事件发生的时候在坐火车,错过了数据库恢复的直播,不过根据相关的新闻,也看出来恢复的过程可以说十分的艰辛,并且最终恢复的数据还是6个小时之前的,也说明数据库的恢复工作很复杂。因为不是运维工作,所以在数据库备份操作上的经验还是比较少的,但是还是有一些接触的,说下自己的见解。

  1. 多机备份是必须的,最好有异地容灾方案,当一台出现问题,另一台可以及时顶上。
  2. 数据库等重要系统在指定时间开放操作,有效杜绝疲劳操作或者恶意操作。
  3. 定期检查备份服务器的状态,当出现备份数据的容量或者时间出现问题时要及时进行修复,必要时进行灾难演练。
  4. 在重要的服务器上将一些危险命令进行屏蔽操作。
    以上是我的个人见解,有不对的地方还请指正
西秦说云 回复

灾难演练还是有必要的,不演练永远不知道问题的核心在哪。不上战场就不知道自己的弱点在哪。

评论
4

bearyes 已获得淘公仔 复制链接去分享

这次事件给我们的警示:

不要疲劳驾驶,喝酒不上机,上机不喝酒,尤其别动数据库;
建议要对rm命令设置alias,常见做法是设置别名为mv到指定目录;
备份和恢复验证同在,定期从备份数据进行恢复演练,既验证备份数据是否完整有效,也验证恢复方案是否靠谱;
践行DevOps的无指责文化,尤其是在做事故分析时。事故分析重在定位原因,制定改进措施;
在处理事故时,一定要考虑处理措施是否会引发连锁故障,重要操作三思而行;
应急预案还是要做的,此次事故响应和修复周期非常长,备用硬件不给力,且丢失数据,对用户而言是难以接受的;
千万不要在改进措施中增加线上操作的领导审批环节,不仅于事无补,还会影响效率;

2

德哥 已获得淘公仔 复制链接去分享

给Gitlab提点建议:

4. 调整 PostgreSQL 的配置,线上环境中 PGSQL 的连接数过大,导致备份失效,从8000降到2000,或者使用数据库连接池。

PostgreSQL支持为superuser保留连接,可能比上面这种改进方法更好。
另外也支持为用户组设置连接limit。

通过修改PG内核,还可以做到为replication用户保留了连接。

评心静气 回复

这个涉及到内核的修改,要实现。。。有点难度吧!

德哥 回复
        if ((!am_superuser || am_walsender) &&
                ReservedBackends > 0 &&
                !HaveNFreeProcs(ReservedBackends))
                ereport(FATAL,
                                (errcode(ERRCODE_TOO_MANY_CONNECTIONS),
                                 errmsg("remaining connection slots are reserved for non-replication superuser connections")));

这一段稍微改一下

小柒2012 回复
回复@德哥:

德哥 都上代码了~~

评论
3

mikifuns 已获得淘公仔 复制链接去分享

很庆幸 Gitlab这次事件是公开处理的,从后期多方的建议里我发现了点细节
首先,小哥高工作负载,混混当当的就去处理数据库了,感觉不应该.各行各业规则不同但相信大部分都要求操作者必须休息好有清醒的头脑,这次事件应该会略微改变gitlab的工作表策略
其次,这次事件中6个备份方案全部失效,这就代表这些方案有很大的漏洞.所以在后期专家也给gitlab提出了一些意见,所以这些备份方案应该有事前演练模拟确保可行性才可以.
第三,事后2nd Quadrant的CTO – Simon Riggs 在他的blog上也发布文章 Dataloss at Gitlab 给了一些非常不错的建议:

1.关于PostgreSQL 9.6的数据同步hang住的问题,可能有一些Bug,正在fix中。
2.PostgreSQL有4GB的同步滞后是正常的,这不是什么问题。
3.正常的停止从结点,会让主结点自动释放WALSender的链接数,所以,不应该重新配置主结点的 max_wal_senders 参数。但是,
停止从结点时,主结点的复数连接数不会很快的被释放,而新启动的从结点又会消耗更多的链接数。他认为,Gitlab配置的32个链接数> 太高了,通常来说,2到4个就足够了。
4.另外,之前gitlab配置的max_connections=8000太高了,现在降到2000个是合理的。
5.pg_basebackup 会先在主结点上建一个checkpoint,然后再开始同步,这个过程大约需要4分钟。
6.手动的删除数据库目录是非常危险的操作,这个事应该交给程序来做。推荐使用刚release 的 repmgr
7.恢复备份也是非常重要的,所以,也应该用相应的程序来做。推荐使用 barman (其支持S3)
8.测试备份和恢复是一个很重要的过程。
引用

但是从中也发现的问题是:gitlab的员工并不熟悉PostgreSQL....致命伤
最后,我觉得运维应去尝试用脚本去处理而不是自己手动处理这些..

1

51干警网 复制链接去分享

对于这种技术大神来说,随手删删数据然后恢复,并且通过直播的形式找回来。顺便上上全球各大科技媒体新闻的事情,我等吃瓜群众只能围观。
我来说说我平时建站的备份策略。
对于服务器来说有了阿里的快照这个神器,就不怕它数据误删之类的。像异地容灾,自动备份然后传到云盘的方式我是不削一顾的。阿里云快照万岁~ 么么哒

鬼才神兵 回复

他们也应该是有这种策略的,只是5重备份都不能用了!多点备份还是有必要的!

51干警网 回复

5重备份都没起作用。还不是就备份一个然后起作用呢。

西秦说云 回复

GitLab使用了Azure的快照,但是没有给DB开快照,就出现了问题。

51干警网 回复

用阿里云的啊。

小哀女王 回复

所以说数据库也要用 RDS 之类的,而不是自建。

西秦说云 回复

对,用RDS会相对有数据安全问题。不过依然建议自己做好安全备份问题。RDS可解决不了运维小哥drop掉所有数据的问题

小哀女王 回复

最低化权限分配,我看了 RDS 的备份是无法删掉的,RAM 里面也可以权限控制

评论
3

鬼才神兵 已获得优酷VIP季卡 复制链接去分享

在youtube上看直播到凌晨,最后GitLab的工程师在总结的时候瞌睡虫已袭脑,实在坚持不住。
5重备份都不能用的情况确实少见,再加上我本身不混计算机行业,也没有操作过这么大的数据量的数据库,经验不多,但港真,备份之路,任重而道远。
可能稍差点的使用phpmyadmin备份数据库,稍再好点的命令行备份,再高点的编写脚本自动备份到其它空间。但无论用什么方法进行数据库的备份,但数据的完整性也是重中之重。
对于我而言,技术有限,没有什么特别高深的方法,没有大数据库实操过,所以有错误和不足请指正。
但每次备份完成后都要进行数据完整性验证,如果备份大小和数据库实际大小相差较大,那肯定是备份有问题了!
我在现实中进行备份的时候如果数据库小基本是采用多份备份,如果数据量比较大,基本是多点备份,自动脚本备份到专用备份机器,或是分卷存入OSS。利用计划任务进行定时备份。
目前正在学习对数据库进行增量备份,对于数据量较大的数据库不可能每次都备份一份完整的数据库,所以增量备份显得很重要,这样恢复起来也是比较方便。
如果以后能遇到数据量较大的数据库,再实践总结经验吧!

2

luneice 复制链接去分享

数据的重要性不言而喻,几乎所有的业务都离不开数据,那么对待数据的态度也应该高度重视。我的想法是使用两个独立运行在不同主机数据库,数据库A和数据库B。然后提供一个访问接口I,I的功能应该满足这样几点:
1.只要是涉及到不更改数据的查询默认访问A(前提是A正常)
2.只要是涉及到更改了数据的查询默认都访问
3.一旦有一个数据库故障,所有查询访问正常的那个,并发出预警故障的数据库,及时去修复。
4.如果两个都出问题了,慢慢跑路吧……
双数据库操作,可能会影响到某些效率,对某些影响效率的操作进行优化,降低影响。

西秦说云 回复

双机并不代表数据安全,备份还是应该做的。

评论
1

芬达iamfander 复制链接去分享

国外的数据库管理貌似比国内的差啊,前段时间炉石传说也出现数据库故障,备份不可用呢,说是暴雪那边DBA运维的不是网易这边运维。

鬼才神兵 回复

这个还真不知道呢

西秦说云 回复

这个就不清楚了。或许是甩锅。

评论
1

azinoa 复制链接去分享

从管理角度上说:
1、敬畏生产环境,人为操作总会出现操作失误;
2、有加班到项目本身是项目管理不善。

技术上说:
1、定期数据备份或数据快照;
2、多库容灾机制;

西秦说云 回复

确实,加班肯定是有原因的。要么是工作分配不合理,要么是工作效率不高。

评论
1

sxx1314 复制链接去分享

备份最重要的是校验备份完整和正确性,否则就算100重备份都是无用功。所以也提醒了大家,数据库之类备份脚本/程序加上成功备份且简单校验判断以及存储成功判断是必要的。另外就是日常维护时root权限使用了,sudo rm -rf / 的白痴做法现在依旧有人会犯

西秦说云 回复

不少人总是忽悠新手执行 rm -rf 命令,真是太坏了

评论
0

51干警网 复制链接去分享

看鬼才提到masql备份,那上rds啊。也是自动备份~ 哈哈哈

鬼才神兵 回复

哈哈!如果是好产品能盈利,RDS是不错的选择呀!现在投入不能产出看来就太贵了!

51干警网 回复

高品质的服务需要很大的成本的。像其它的便宜货你敢用吗?

聚小编 回复

94~

小柒2012 回复

RDS 现在针对个人用户是有点贵

评论
0

人事以非 复制链接去分享

为何不用阿里云(ง •̀_•́)ง

西秦说云 回复

哈,可能是他们的主要用户还是海外用户,目前阿里云在海外节点上不如AWS和Azure

评论
0

1847738211627475 复制链接去分享

有个客户把10年的企业数据用空数据库还原复盖了。最终花了三天时间,通过完整备份加差异备份恢复到前一天。备份永远不会多,一次问题就够呛。

西秦说云 回复

确实,备份不是为了不出事,而是为了万一出事,还有的救。

评论
0

vic.86 复制链接去分享

工程师也是人,人谁无过,敢于承担,就是最大的补救措施

西秦说云 回复

确实,不怕犯错,怕犯同样的错和犯错后不改。

评论
0

溪欲焰 复制链接去分享

人非圣贤孰能无过,公司对员工是不念百般好只看一时遭。有胸怀的企业才适合这样的人才栖身。赞

西秦说云 回复

Gitlab这次的危机公关做的是非常不错。

评论
0

webghost 复制链接去分享

众所周知,使用sql误删数据库,即便数据库做好了主从备份,从库也同时会执行误删命令的。这和硬件故障导致的数据丢失情况不同。

西秦说云 回复

是的,所以即使是云数据库,也无法完全解决这样的问题。

评论
0

天空补天 复制链接去分享

我以为内容是讲如何恢复的,结果就是报道了一下而已!如果能讲恢复过程或方法告诉大家就非常完美了。还有视频连接有不?想去学习学习!

西秦说云 回复

视频在Youtube上,发连接大家未必看的到啊。

评论
0

聂焱 复制链接去分享

能够最终恢复,得感谢之前的备份,"将来的你,一定会感谢现在做好备份的自己!"

西秦说云 回复

确实,不要到出了问题才想起自己没有备份。

评论
0

zhlhuang888 复制链接去分享

之前傻逼同事回滚了数据库,还好利用biglog 通宵回复了!

西秦说云 回复

权限不能乱放手

评论
5