2月2日，当我们依旧在享受春节假期的时候，却不知大洋彼岸的Gitlab经历了一次惨痛的运维事故。
一位操作员为解决一个恶意攻击的问题，在工作到深夜并极度疲劳的状态下，误删除了主数据库的数据！在这位操作员意识到问题并立刻终止了移除文件夹操作，但是已经太迟了——300GB的文件只剩下4.5GB。
Gitlab随后试图通过可用的备份文件用于恢复生产环境时，他们发现，采用的五种备份方式居然鬼使神差地在这一刻都失效了！最终导Gitlab官方网站宕机长达十个小时。
虽然Gitlab最终挽回了部分损失，但仍然丢失了6个小时的数据。
非常值得尊敬的是，Gitlab官方在youtube上直播了的整个恢复过程，为所有的IT运维人员敲响警钟：自己的运维情况如何？如果这件事情发生在自己身上，会不会做得更好？
GitLab使用的五种备份机制分别是：
· LVM快照（24小时做一次）;
· 日常备份（24小时做一次）;
· S3备份;
· Azure备份（只对NFS 启用，对数据库无效）;
· 自动同步;
但是当这次事故发生时，所有备份全部无效！作为一个在数据保护领域工作多年的老司机，这件事引起了我强烈的兴趣。究竟写备份是如何失效的？对其他数据库管理者，通过这件事情，我们能学到什么？
首先，Gitlab将LVM的复制周期设置为24小时。作为一个防止误操作的屏障，这个周期明显太长了。但是好在这个备份副本具有比较高的可靠性，在实在没办法的时候还可以指望得上。实际上Gitlab最后就是利用了LVM的复本对数据实现了恢复。这本应是最终的一道屏障，事实证明，却是可用的唯一屏障。
日常备份也是24小时进行一次，但最后却发现日常备份实际上并没有生效。“高效运维”公众号的笔者认为，这里的日常备份指的是Gitlab官方提供的命令行脚本，每天打包一次。很多数据库高手貌似都喜欢使用命令行脚本，但是，一个备份作业是否完成是需要反馈的。命令行指令没有完成的反馈，很容易就淹没在各种交互信息里了，谁也不知道这个日常备份已经有多久没有执行了。另外，如果如推测所言，这个备份只能保护数据库本身，对整个计算系统是没有保护的。
原文还提到了基于数据库的pg_dump命令的备份，但是因为数据库版本的问题，已然失效。
Gitlab利用Azure进行备份，但是备份只针对了NFS服务器而没有针对数据库服务器。原文还提到了一个不能用的S3备份却没有说明原因，此处不作分析。
管理员们还急中生智，想利用一个往预发布环境同步数据的同步程序来恢复数据，但是同步