2月2日，当我们依旧在享受春节假期的时候，却不知大洋彼岸的Gitlab经历了一次惨痛的运维事故。

一位操作员为解决一个恶意攻击的问题，在工作到深夜并极度疲劳的状态下，误删除了主数据库的数据！这位操作员意识到问题并立刻终止了移除文件夹操作，但是已经太迟了——300GB的文件只剩下4.5GB。

Gitlab随后试图通过可用的备份文件用于恢复生产环境时，他们发现，采用的五种备份方式居然鬼使神差地在这一刻都失效了！最终导致Gitlab.com 官方网站宕机长达十个小时。

虽然Gitlab最终挽回了部分损失，但仍然丢失了6个小时的数据。

（Gitlab.com网站宕机公告，图片来源于网络）

非常值得尊敬的是，Gitlab官方在youtube上直播了的整个恢复过程，为所有的IT运维人员敲响警钟：自己的运维情况如何？如果这件事情发生在自己身上，会不会做得更好？

GitLab使用的五种备份机制分别是：

• LVM快照（24小时做一次）；
• 日常备份（24小时做一次）；
• S3备份；
• Azure备份（只对 NFS 启用，对数据库无效）；
• 自动同步；

但是当这次事故发生时，所有备份全部无效！作为一个在数据保护领域工作多年的老司机，这件事引起了我强烈的兴趣。究竟这些备份是如何失效的？对其他数据库管理者，通过这件事情，我们能学到什么？

（图片来源于网络）

首先，Gitlab将LVM的复制周期设置为24小时。作为一个防止误操作的屏障，这个周期明显太长了。但是好在这个备份副本具有比较高的可靠性，在实在没办法的时候还可以指望得上。实际上Gitlab最后就是利用了LVM的复本对数据实现了恢复。这本应是最终的一道屏障，事实证明，却是可用的唯一屏障。

日常备份也是24小时进行一次，但最后却发现日常备份实际上并没有生效。“高效运维”公众号的笔者认为，这里的日常备份指的是Gitlab官方提供的命令行脚本，每天打包一次。很多数据库高手貌似都喜欢使用命令行脚本，但是，一个备份作业是否完成是需要反馈的。命令行指令没有完成的反馈，很容易就淹没在各种交互信息里了，谁也不知道这个日常备份已经有多久没有执行了。另外，如果如推测所言，这个备份只能保护数据库本身，对整个计算系统是没有保护的。

原文还提到了基于数据库的pg_dump命令的备份，但是因为数据库版本的问题，已然失效。

Gitlab利用Azure进行备份，但是备份只针对了NFS服务器而没有针对数据库服务器。原文还提到了一个不能用的S3备份却没有说明原因，此处不作分析。

管理员们还急中生智，想利用一个往预发布环境同步数据的同步程序来恢复数据，但是同步一旦完成，这个空间自动就清空了。这根本就不是，也不应该是一个数据备份机制的一部分。

从数据库管理员的角度来看，从此次事件中得到的教训包括：

1. 让你的备份机制能够主动反馈结果，管理员必须能够至少知道备份是成功还是失败；
2. 让你的备份机制能够完整覆盖数据库和文件系统以及整个计算环境，而不是仅仅针对数据库本身；
3. 经常演练。上面列举的第二、第三和第四个备份方式可行不可行，哪怕只进行过一次演练就应该发现漏洞；
4. 做一个应急预案。在这次事故中看到Gitlab的响应和修复措施几乎无章可循，完全没有事先的规划和设计。

从数据保护的专业角度看，虽然Gitlab号称采用了五种备份机制，但是仔细看来，却显业余。鉴于此次已经发生的Gitlab事故，以及未来即将发生的“Gitlab”事故，企业和网站应该开始思考：自己的数据库是否正在裸奔？其数据保护和容灾机制是否健全？应该向哪些厂商寻求专业保护？

（图片来源于网络）

在软件定义存储解决方案方面具有16年经验的飞康软件公司，针对这种情况为客户提供了数据保护和容灾产品Continuous Data Protector（CDP）。

飞康CDP可以对内部数据中心和外部云（如Gitlab的S3和Azure）进行统一管理，充分利用外部云的高性价比，并可以轻松在云间灵活跳转，实现更高的性价比和灵活性。

飞康CDP是基于磁盘的、新一代备份与容灾一体化解决方案，能够帮客户将文件/数据库/操作系统实现实时备份与瞬间恢复，可以在系统出现问题时迅速将数据恢复到数分钟以前，这极大地保证了业务的连续性，同时避免出现Gitlab事故中的因备份恢复延迟导致大量数据丢失的现象。

飞康CDP备份/容灾一体化解决方案，真正以快速恢复服务为第一目标。无论用户的应用或者系统乃至数据中心发生何种意外，例如，恶意的程序破坏、文件损毁、人为误删误改、操作系统宕机、硬件故障，甚至整个机房毁于意外，在飞康CDP的全面保护下，都能最大程度地保证企业数据损失（RPO）降到最低，业务中断时间（RTO）最短。

最后，一体化的飞康CDP备份/容灾技术，使任何灾难的发生都不再是致命的，用户很轻松就能获得备份和容灾的双重效果。