2020年3月24日到2020年4月14日，是本站经历过的最黑暗的20天。
在这20天里，先是经历了MySQL官方docker镜像的bug导致MySQL数据不正常，经过了各种翻箱倒柜，找到了一个古老版本的网站备份，还原了2020年1月 备份的数据。在此期间，也终于意识到了两点：
1. 无论何时都不能停止对数据的备份；
2. 不要轻易的删除备份数据；
3. 如果有迁移任务，一定要停止备份并删除备份数据，一定要在迁移任务完成或rollback 任务完成之后重新启用备份。
也许是对于Redhat旗下产品过于自信，也许是对于“个人网站的数据”重视度不够高，在网站恢复后，我只是重新启用了本地备份的task，并没有启用远程备份，究其原因……懒，再加上那段时间忙着离职之前的一些工作，毕竟不想把过多的ticket都handover给其他同事。
然后逗比的一幕又发生了……
由于GlusterFS的一些问题（究其原因我到现在都没研究明白，replica节点数为4 MySQL容器就异常，为3就啥问题都没有。）我的MySQL又崩了，而且这回崩得特别彻底，连同MySQL带周期备份的sql文件，都是有问题的。嗯，一切又回到了3月24日。
为此我不得不重新再回到1月14日的备份，重新整理数据。
找到site issue的root cause固然重要，但是这也充分的说明了我的意识还是存在偏差，为什么偏偏数据备份这么重要的工作没有做好？而且还是两次。于是我再度对于第二次site issue做出了总结：
1. 对于新版GlusterFS的研究不够透彻，没有在实验环境下测试过就匆匆的让其上了“Production environment”。再挖细一点就是当时将博客迁移到K8S的时候太注重“速度”，而没有充分的在实验环境上做测试。
2. 对于本地搭建的文件存储过于信任，想当然的认为container跑起来了、backup的task跑起来了，backup文件生成了就OK了，没有验证DB是否能正常的写入数据到存储，也没有验证备份的sql文件是否是一个正常的文件。
3. 刚刚提过，sql文件没有做异地备份，始终是存在本地。
基于对此次site issue的review，下一步应该做的就是改进的action plan:
1. 介于目前storage上已经有大量的数据，故不可能完全将业务下线然后充分测试之后再度上线，故目前只能是在本地再度建立一套测试环境，确认其可用性并对用法进行更进一步的研究。（1 month）
2. 增加验证机制，周期性（每周？）启用新的DB container，导入sql文件，验证文件可用性。（1 week）
3. 启用远程备份功能（Today）