从GitLab数据库被删无法完全恢复看数据备份的重要性

2017-02-11 15:05 阅读 1,062 次 评论 0 条

GitLab百度百科

GitLab 是一个用于仓库管理系统的开源项目。使用Git作为代码管理工具,并在此基础上搭建起来的web服务。

GitLab误删事件

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

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

GitLab的五大备份机制

①常规备份(24小时一次)

②自动同步

③LVM快照(24小时一次)

④Azure 备份(支队NFS启用,数据库无效)

⑤S3 备份

这次事故发生时,所有备份全部无效!幸好还有一个“也许可行”的六个小时前的备份,数据成功的被恢复回来。针对这次事故,Gitlab 也给出了自己的解决方案和未来针对备份的ToDo list:

1. 更改服务器终端的颜色来区分生产环境(红色)、测试环境(黄色)。

2. 定期检查数据库备份的目录,查看备份的数据是否成功备份。

3. 添加备份提醒,定期检查S3 Bucket的大小,如果备份大小小于数据库大小、备份频率超过设定的时间,就发送警告。

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

造成的损失 

1.6小时的数据丢失2.大约丢失5037个项目(4613个常规项目,74个fork, 350个import)

3.可能丢失了707个用户

4.网站宕机超过12个小时

5.大约丢失4979个提交记录 

数据库备份的重要性与操作性

一个系统是需要做数据备份的,但是,你会发现,GitLab这个事中,就算所有的备份都可用,也不可避免地会有数据的丢失,或是也会有很多问题。理由如下:

备份通常来说都是周期性的,所以,如果你的数据丢失了,从你最近的备份恢复数据里,从备份时间到故障时间的数据都丢失了。

备份的数据会有版本不兼容的问题。比如,在你上次备份数据到故障期间,你对数据的scheme做了一次改动,或是你对数据做了一些调整,那么,你备份的数据就会和你线上的程序出现不兼容的情况。

有一些公司或是银行有灾备的数据中心,但是灾备的数据中心没有一天live过。等真正灾难来临需要live的时候,你就会发现,各种问题让你live不起来。你可以读一读几年前的这篇报道好好感受一下《以史为鉴,宁夏银行7月系统瘫痪最新解析》。

所以,在灾难来临的时候,你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作,但也会导致数据丢失,而且可能长期不用的备份系统很难恢复(比如应用、工具、数据的版本不兼容等问题)。

之前有一篇《分布式系统的事务处理》,你还记得下面这张图吗?看看 Data Loss 那一行的,在Backups, Master/Slave 和 Master/Master的架构下,都是会丢的。

GitLab误删除数据库事件的几点思考

所以说,如果你要让你的备份系统随时都可以用,那么你就要让它随时都Live着,而随时都Live着的多结点系统,基本上就是一个分布式的高可用的系统。因为,数据丢失的原因有很多种,比如掉电、磁盘损坏、中病毒等等,而那些流程、规则、人肉检查、权限系统、checklist等等都只是让人不要误操作,都不管用,这个时候,你不得不用更好的技术去设计出一个高可用的系统!别无它法。

AWS 的 S3 的的高可用是4个加11个9的持久性(所谓11个9的持久性durability,AWS是这样定义的,如果你存了1万个对象,那么丢一个的时间是1000万年),这意味着,不仅仅只是硬盘坏,机器掉电,整个机房挂了,其保证可以承受有两个设施的数据丢失,数据还是可用的。试想,如果你把数据的可用性通过技术做到了这个份上,那么,你还怕被人误删一个结点上的数据吗?

版权声明:本文著作权归原作者所有,欢迎分享本文,谢谢支持!
转载请注明:从GitLab数据库被删无法完全恢复看数据备份的重要性 | 术与道的分享
分类:数据库渐入 标签:,
1024do.com导航_术与道导航平台

发表评论


表情