2017年那个春节，我正吃着团圆饭，手机炸了。
执行了删库操作，致使300G数据被通过rm -rf命令删除，五套备份方案，全部归于失效，他们最终于进行直播恢复过程，让全球几十万人予以围观。
我盯着屏幕，筷子掉在地上。
并不是由于技术具备高超的特性而是鉴于我们公司所进行的备份其情形与他们的完全相同，是定时去运行一个，而后将其放置到NAS当中觉得这样便不会出现任何差错。
那晚，我未能入眠，于客厅一直坐到天亮。凌晨四点，起身去把电脑打开，对公司全部数据库的备份日志逐一进行翻阅。
发现三个备份文件是0字节。有一个，断开了。
哎，断开了呀。备份期间网络出现了突然的中断，日志仅仅只有一行写着“Lost ”，可是根本没有任何一个人知晓。
备份了但没备份
存在一张表，在半年之前添加了json字段，未出现报错情况随后是退出了吗？并非如此，它持续运行了，然而备份文件之中那张表的记录全部都是NULL。
我为什么没发现？
因为脚本只检查了返回值。0就是成功。
恢复演示时才发现——那张表的数据，全丢了。
我把备份文件解压出来，用tail -1看了一眼。
结尾的那一行呈现的是“– Dump ”，然而处于中间的部分呢，你始终没办法知晓。
这便是薛定谔的备份，若不打开瞧一下，它既属于好的范畴又属于坏的范畴。直至你切实恢复的那个时刻，猫才会向你告知它究竟是死还是活。
物理备份
往后换成了去做物理备份，速度着实是快，有着400G的库，两个小时就跑完了。
快又怎样。
有没有跨版本恢复这回事呢？结果报错了。MySQL 5.7备份出来的文件，别指望能恢复到8.0版本。因为存在引擎依赖，存储格式也发生了变化，要是直接把数据文件拷贝到新版数据库里，随后启动，那能成功启动才怪呢。
同事小王，他不信邪，就在上个月，进行了一次操作。结果呢，服务启动失败了，而err日志显示，table space格式不正确。
我冷冷看着他：“你不是说物理备份快吗？恢复啊。”
他的脸色呈现出白色，最终，我们耗费了一整日的时间，从冷备磁带当中缓缓地进行恢复，业务停顿了6个小时。
备份锁表
我第一次在生产环境做备份的事，至今记得。
那个下午三点的时候，线上的业务忽然就卡死过去的了，每一项查询都处于等待的状态之中。报警的电话一个接着一个拨打进来，运维总监瞬间就在群里面询问到底是谁动了数据库。
我身体抖动之下打开MySQL ，发觉有一个会话将整个数据库锁住了。
那天我才知道，默认是需要锁表的。
随后，我瞒着他人，悄悄地对备份脚本作出了修改，增添了– – 这一内容。
但有些事情，加了参数也不够。
恢复演练
公司每个季度做一次恢复演练。
首次进行演练，针对10GB的测试库运用予以恢复，运行了半小时，随后SSH会话中断。再次运行，又出现断开情况。这已经是第三次了，我目不转睛地盯着屏幕，最终等到其执行完毕。
后来用多线程恢复，8分钟，全程无感。
现今我所采用的备份策略讲出来甚是愚笨：存在逻辑备份，有物理备份，还有增量，此三者并行。
每到周日的凌晨2点，会进行全量的操作；每天凌晨4点时，会采用命令并加上— 选项然后进行压缩，之后将其存储在两个不同的地方；实时的会被传输到另外的一个机房。
但还不够。
有一回演练，我把用于生产目的的库里面的数据，恢复到了用于测试的环境之中，在这个过程里，我察觉到，使用进行备份操作的时候，遗漏了mysql这个系统库。
人麻了。
验证备份
我当下撰写了一个脚本，每一次备份结束之后，随机抽取十张表，对 COUNT(*)进行对比源库工作。
还要在测试环境找一台机器做全量恢复演练。
分别在每个月，手动去跑开一次恢复脚本，再以此去记录RTO，来判断其是不是真的达到标准，不能仅仅因为只看备份日志里写着“”，就觉得自己处于安全状态而毫无担忧了。
有朋友问我，备份的源码看了有用吗？
有用。
看了源码之后，才清楚知道，导出大字段之际内存究竟是怎样予以分配的，会有OOM风险的缘由是什么。阅读了的多线程实现内容，才弄清楚明白，为何它比官方工具快7至8倍。
但我不会跟你讲源码。
救过我一命的并非高端技术，而是事故后，我未继续吃团圆饭，是从NAS那堆过期备份文件里，手动挑出一份未被覆盖的老版本，甚至可能是某个同事随手写的shell脚本。
那些显得愚笨的办法，那些看上去并非尽善尽美的土式方法，才是实实在在的最终一道防线！
