备份重于一切:远离“Gitlab删库事件”,QBackup是你的最佳选择!

作者简介:孙朝阳 沃趣科技高级产品经理。

案发现场: Gitlab删库事件回顾

Gitlab是大家很熟悉的开源Git代码托管工具,国内公司大多使用社区版自行搭建私有化的内部代码托管平台。

Gitlab 的数据库采用PostgreSQL集群,db1.cluster和db2.cluster。另外还有db1.staging 和 db2.staging两台staging数据库 。

2017/01/31 18:00 UTC Gitlab遭受攻击,运维工程师采取一系列措施抵御。

2017/01/31 22:00 UTC 运维工程师发现db2.cluster复制延迟滞后,尝试清空了data目录后,依然拒绝复制。

2017/01/31 23:00 UTC 运维工程师在试过多种方法后,认为删除db2.cluster的data目录(已经是空目录)可能有用,但操作的时候,却误删除了db1.cluster的data目录。待工程师反应过来的时候,原本300GB的数据仅剩下4.5GB。

2017/02/01 18:14 UTC 经过了17个小时的奋战,以及YouTube全程直播并求助,Gitlab 数据库终于恢复成功。

Gitlab具备多重数据库备份,但恢复的时候,竟然差点找不到一个可用的。

  • 日常备份24小时执行一次。找到的备份文件仅有几个字节大小,明显早已失效。pg_dump本应使用9.6的,但实际运行的却是9.2的版本,所以没有结果。
  • Azure上的硬盘快照,仅对NFS启用了,对数据库的完全没开启。
  • 备份到S3也没成功,都是空的。
  • 同步到staging的脚本虽然是成功的,但是同步过程中会删除webhook数据。实际上staging根本就不应该承担备份的角色。
  • LVM快照24小时执行一次,幸好6个小时前工程师偶然做过一次手动快照,否则丢失的数据会更多!

恢复的详细过程不再赘述,可以参考官方的说明: https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

最后工程师们使用db1.staging上的那份6小时前的快照恢复数据库成功(没有webhook数据,后来从另一份拷贝恢复了部分),但丢失了6小时的数据

详细的损失如下,主要是工程、fork等需要存在数据库里的信息丢失,代码和wiki没有受到影响。

±6 hours of data loss

4613 regular projects, 74 forks, and 350 imports are lost (roughly); 5037 projects in total. Since Git repositories are NOT lost, we can recreate all of the projects whose user/group existed before the data loss, but we cannot restore any of these projects’ issues, etc.

±4979 (so ±5000) comments lost

707 users lost potentially, hard to tell for certain from the Kibana logs

Webhooks created before Jan 31st 17:20 were restored, those created after this time are lost

考虑到Gitlab曾计划推出自己的私有云服务,此次事件对其声誉也是个沉重的打击。

经验教训:备份姿势全方位

相信从本次的Gitlab事件,所有人都可以很明显的看出该公司在备份环节存在的问题:全部的备份都没有验证过!!!也许是上帝仁慈,幸好运维工程师手工做过一次lvm快照,否则就只能恢复到24小时前了!

其实,在备份领域,备份文件的验证一直是个难题,要保证备份100%可用,最稳妥的方法自然是使用该备份恢复出完整的数据库。然而,随着数据库的不断增大,恢复的时间/空间成本会越来越高(想象一下完整恢复几十TB的数据库需要多长时间!)

那么该如何避免Gitlab此次遇到的问题呢?

由沃趣科技自主研发的QBackup数据库备份云平台,可极大缩短恢复时间,实现秒级数据库验证,同时具备多项极具吸引力的特性。

(QBackup数据库备份云平台)

  • 秒级验证。QBackup 由备份恢复至完整的可访问数据库,仅需要几十秒,验证过程耗费时间极短,成本极低。
  • 持续备份。Gitlab的定时备份始终存在时间窗口,一定存在数据丢失,区别仅仅是多与少的问题。QBackup采用CDP技术,数据库的每一个变动后都会实时备份,真正的实现了数据零丢失。
  • 秒级时间点恢复。QBackup实现了Point-in-time recovery ,可以秒级恢复数据库到指定的时间点。
  • 配套完善。Gitlab官方自己检讨称,诸多备份流程失效不仅没有任何人发现,竟然连一条告警都没有。QBackup具备完善的配套措施,在添加需要保护的数据库后,自动配套监控及报警,第一时间发现异常。

由Gitlab此次的恢复过程所遇到的问题来看,QBackup的核心功能,几乎都是针对数据库备份中最重点的部分研发,在极大的降低了企业备份环节成本的同时,最重要的是从根本上提高了数据库的安全性。

客户案例:实践是检验产品的唯一途径

某国内排名前列的券商,其某系统为投资顾问及客户经理提供业务办理、报表分析、绩效考核、机构查询、资金统计等功能。以往该系统数据库的日常备份在其数据量超过5TB的时候就已经无法正常进行。

该客户于2016年底采用沃趣QData+QBackup数据库备份云平台,实现了大规模数仓的实时备份,数据库高峰期每天的数据变化量高达2TB,QBackup数据库备份云平台实现了该应用数据库的CDP实时备份,并提供秒级时间点恢复、快速备份验证、备份失效报警、克隆库镜像等安全高效的功能。

(客户案例架构解析)

QBackup数据库备份云平台具备了大规模数据库的快速备份能力,为用户所有的数据库提供安全完成的服务。如今,数据对于很多企业来说就是最重要的资产,更加需要时刻强调“备份重于一切”:远离“Gitlab删库事件”,QBackup数据库备份云平台是企业的最佳选择!

原文发布于微信公众号 - 沃趣科技(woqutech)

原文发表时间:2017-02-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云加头条

腾讯云“开发者实验室”与“DCDB”产品揽获工信部信通院两大年度奖项

11月17日,由高效运维社区主办的GOPS全球运维大会暨第二届中国运维行业年度盛典隆重召开,全球运维大会也是中国首个专属运维行业的盛会,面向互联网及传统行业的广...

1390
来自专栏一名叫大蕉的程序员

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式...

2177
来自专栏企鹅号快讯

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系...

3769
来自专栏java一日一条

大型网站架构体系的演变(下)

在做扩展满足了基本的性能需求后,我们会逐渐关注“可用性”(也就是我们通常听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。

661
来自专栏FreeBuf

有人在偷窥?智能摄像头真的“聪明”吗?

写在前面的话 在这个物联网当道的时代,类似咖啡机、汽车、冰箱和灯泡这样的东西都开始接入互联网了,而且更加智能化了。而且很多城市甚至还出现了智能街道。智能摄像头其...

4056
来自专栏指尖下的Android

从一个聚合SDK的Bug解决所展开的人生思考

最近,公司有个做聚合SDK的老铁要离职了,然后它的锅就甩给我了,话说,本来开会的时候说和另一个同事一人负责半个月

2972
来自专栏跨界架构师

分布式系统关注点——「负载均衡」到底该如何实施?

        前面两篇《分布式系统关注点——初识「高可用」》、《分布式系统关注点——仅需这一篇,吃透「负载均衡」妥妥的》看完后,相信大家对实现高可用的思路和负...

1391
来自专栏互联网技术栈

读《大型网站技术架构》

《大型网站技术架构》是自己接触的第一本架构知识的书籍,还是在14年时买的实体书,前后读了几遍,颇有所得,后来实体书被朋友借走再没归还,也就没再翻过。

1032
来自专栏小白课代表

再见,广告。

火绒已经给小伙伴们推荐过好多次了,今天详细讲一下如何使用Adblock Plus。

1493
来自专栏沃趣科技

Gitlab删库事件回顾,备份手段还停留在“原始社会”?

作者简介:孙朝阳 沃趣科技高级产品经理。 Gitlab简介 Gitlab是大家很熟悉的开源Git代码托管工具,国内公司大多使用社区版自行搭建私有化的内部代码托...

3486

扫码关注云+社区

领取腾讯云代金券