别的方向不敢说，至少在数据库行业，我敢拍胸脯说，如果你的数据库不考虑备份，连最起码的备份都没有，一点都没有的话，那么你搞那么多的优化和改进最后都可能被一次故障抹平。

  让我现在很难理解或者焦急的是，我了解的很多行业/公司里面，其实备份做得很一般，最普遍的一类问题是只有备份，没有恢复。恢复都没试过，没有演练过，你备份有啥意义。在DBA 1.0的时代，对于DBA的定位，最重要的职责就是数据恢复，这里要强调的是，最重要的，没有之一，当然到了DBA 3.0甚至更新的版本迭代，不那么重提备份恢复是因为现状应该会很好了，相比于云时代的挑战，备份恢复已经相对成熟了，所以没有放入以前的那个位置，但是我们的状态还是很早之前的。

    别怪我说话直，是这么简单的道理，好像大家都不知道，还需要碰到问题吃点亏才能长记性，这个代价实在是有些大了。

    我的手机里有很多的朋友，以至于我每隔一段时间就会自然的收到一些千奇百怪的问题。有的朋友的数据库遇到了无备份的破坏场景需要恢复，有的是逻辑问题导致的数据丢失，一旦发生问题，少则是丢失数据，多则影响核心业务，损失都是成百上千万的。都说运维部门只花钱不挣钱，如果在这个时候还捅出篓子来，那么我们的工作会更加被动，甚至极端情况下有些同学的职业生涯就在此转折。

    我现身说法来讲一个例子，今天对于备份的认识算是更加深刻了一些。我们花了很长一段时间，投入了不少的精力来做SQL Server到MySQL的存储过程转义，联调测试。因为处于测试阶段，所以我们就没有考虑像线上业务的高可用或者灾备，在保证功能的前提下，我们先着重于结合业务测试数据。

    因为需要做schema层面的调整，比如一个数据库的名字是testdb_dbo，我们需要修改为testdb,那么在MySQL层面是无法直接修改数据库名字的，所以一种自然的方式就是备份数据，然后重新建库，导入数据。

    我也深深知道这个操作的重要性，所以在备份的时候，做了好几个层面的备份，第一个层级的备份是数据库级的，比如有两个数据库，那么我就对每个数据库生成一个备份，使用的命令类似：

    mysqldump --single-transaction --databases testdb_dbo > testdb.sql

然后做第二层备份，害怕万一遗漏了什么，我做了一个全库备份，使用了--all-database级别的备份

然后我做了第三层级的备份，做了数据文件的备份，这里因为空间的原因，我着重就备份了整个数据库的物理文件，也是按照数据库的文件夹级别来备份的。

    做好了这几个层面的备份之后，我觉得差不多了，于是删除了已有的数据库，创建新的数据库，导入数据，一切看起来都是很顺畅的，从权限和数据表的方案问来说，没有发现什么问题。

    但是过了一天之后，同事给我反馈，存储过程访问不了了，这个时候拿着问题再来看这个问题，我突然发现恢复后的几个数据库里面都没有存储过程了。我突然想起来，我竟然犯了一个错误，那就是做数据库级别备份的时候，竟然没有添加--routines选项，导致存储过程没有备份，带着一丝的侥幸，我查看了数据库级别的备份文件，确实没有procedure的字样，我觉得问题好像麻烦了，然后我打开物理备份，因为是直接拷贝的物理文件，抓狂的是ibdata这样的文件还没有备份，所以物理备份理论上是可以恢复的，但是恢复存储过程，从目前的情况来说，也是不可行的。

    然后回到救命稻草，那就是全库备份，我还在不断的问自己，全库备份是否需要再声明--routines选项。如果没有的话，那么我们这段时间的努力就全白费了。在全库备份中找到了procedure的字样，总算让我有点踏实了，我重新恢复了数据，最后算是把存储过程都恢复回来了。事情到了这一步，其实也算是有惊无险。我想着也给了我敲响了警钟，但是做全库备份还是绝对的不重视，差点因为文件命名的关系，把全库备份给删掉了，幸亏是好的一方面，要不我们接下来该怎么走，可能就比较纠结了。可能是去找历史的备份，或者找一个最近的备份归档，显然那么这个事情会暴露出更多的问题和隐患，最终的结果也会存在诸多的差异。

    有的同学可能会认为运维把自己做好就行了，应用层面出了问题，那么这个锅可能和我们就没有关系了，其实不然。比如应用层面因为逻辑问题导致数据丢失，这个责任和边界很清晰，但是问题还是要解决，结果求助DBA去恢复数据库的时候，发现我们的数据库备份就存在问题，那么这个锅肯定会到我们的头上。这个是我们首要保证的。

    另外一个就是流程化，规范化的落地，比如应用的重大变更一定要备份，可能这个时候备份对于他们来说意义不大，他们可以确实不需要备份等等，但是从流程的角度来说我们还是需要备份的，一旦发生了意料之外的情况，我们还有解救措施。