最近不仅吃得有点儿疲劳了，甚至看故障类的文章也有点儿疲劳了，似乎从来没有这么密集过。有人提议将今天，2月1日定为世界备份日，我觉得是个好提议，如果你同意，在文章末尾的评论里支持吧！

最近连着写了几篇故障文章，说别人家的故障，总有点隔鞋搔痒，看人家笑话的感觉。

先说一个小故事吧，某一年三四月份，我和几个同事一起去拜见某大客户的IT总经理木总，聊大型系统的运维经验，聊我们的管控手段，木总很不屑的说，这些我们都做了好几年了……比较幸运的是，半年后我们的团队开始支持他们的系统，紧接着2个月发生了“由于某些原因将某数据库重启后，系统性能运行非常缓慢，后面发现原因是重启后SGA变为几百兆了，而正常是几十GB”，“某数据库出问题，需要恢复的时候，发现Veritas软件恢复的时候不支持，需要打一个补丁”，“所有的用户权限都是DBA，某天突然应用用户drop了个生产表，需要立即恢复”…..木总原以为这些数据库有备份、有流程、有规范的在运维了，事实上是情况已经不像他以为的那么好。所以我们一直说，运维是个持续的过程，要靠专业的运维团队来做，而且流程规范要与时俱进更新和完善。

今天发生故障的是一家代码托管的创业公司gitlab.com，说实话我第一反应以为是github，虽然名字很像，其实不是。但是，我非常佩服这家公司，能非常透明地把整个故障情况清晰的发表出来，并在故障处理过程中持续的通过推特在更新。当然，这可能跟它公司的性质相关，它必须及时更新，以尽可能保留住这些用户。更多详细的情况，大家可以直接通过这个网址直接查看：https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

http://monitor.gitlab.net/dashboard/db/postgres-stats?panelId=10&fullscreen&from=now-24h&to=now
 

本文不做过多赘述（不想黏贴复制，也可以通过点击原文访问。后一个网址持续空白中，应该恢复后才能用）。

简单介绍一下：

1. 工作了一天，疲惫的工程师YP同学在1月31日23点的时候，想把一个自己以为是空目录的文件夹rm –rf删除了。大概一两秒之后，YP同学突然意识到，他大爷的，是不是搞错机器了！没错，他确实搞错机器了！（旁白：我相信你开车的时候，肯定也遇到过有那么几秒钟你突然回过神来，刚刚是不是差点睡着了！）

2. 23点27分的时候，YP同学终止了这个操作，然后发现，310GB的数据，只剩4.5GB了，99%的数据已经被误删除。

3. 非常不幸的是，之前号称的所有备份都失效了：常规备份（原文是说好像有，但是备份在哪不知道呢）、LVM备份（是24小时一次的。说YP在故障发生的6小时前做了一次，但从恢复进度来看，应该也是失败的）、Azure上的磁盘快照（以为做了，其实没做DB的）、S3上的备份好像也没成功、自动同步程序不稳定，也失效了。

截至本文写稿的时候，推特上显示恢复进度已经达到73%了，1小时5%的恢复进度，可想而知不是通过备份来做的恢复，具体恢复技术暂时不得而知。

我们总在吹牛说，备份重于一切，备份是运维工程师的最后防线。事实上呢？这个例子告诉我们，5重防线都没卵用，因为你没去真正落地。我们在运维群里吹鼻子瞪眼的喊要做好某某检查的时候，并没有把检查结果一一确认，事情就算就做过了，反正相安无事大家也就其乐融融，然后最终悲剧一定到来。作为冲在一线的运维管理者，这种歇斯底里地没有安全感的运维意识如果没有深深刻在骨子里，墨菲小姐的邂逅通常是你最没欲望的时刻。

我还是要说，gitlab.com的善后做得很好了，而且我相信，通过这样一次故障，这公司的运维团队很难再犯同样的错误了。真正值得注意的是，那些暂时还没有出过类似故障的团队或者说公司。

这次故障，从技术层面、运维层面、管理层面，我们有哪些教训可以习得？

• 首先从技术层面来说，这个数据库居然是用slony的,选择这个版本本身很奇怪。主流数据库不管pg也好（本次生产环境），MySQL也好，Oracle也罢，高可用配置已经是基础建议配置了，但选择一个“稳定”版本应该算是基本的技术问题吧。

• 其次从运维层面来说，备份脚本pg_dump失效，是因为数据库从9.2升级到9.6之后，它所需的备份目录不存在，所以备份是失败的。这东西就跟技术无关了。运维的人从来不看么？做升级这种大的动作，难道只是看升级后业务是否还能运转么？

• 从管理上来说，一个是重大变更操作需要实行金手指模式，不要让一个人干这种事情，老司机也会犯错，何况是半夜。另外一个，晚上工作的人，白天通常就好好休息，也就是常说的运维轮班制度。人的工资贵，但人的工资没有数据价值贵。

其实数据库运维中有太多的坑，如果你的数据真的很重要，不妨请一个专业的运维DBA，或者请一个专业的运维DBA团队更靠谱。

Gitlab.com的数据恢复过程一直在直播中，如果你有兴趣，可以现在到B站看，3个DBA恢复过程中的对话也挺有趣的：http://live.bilibili.com/19398

最后问个问题，你公司最核心的数据库最近一次恢复测试是什么时候？

作者介绍