罪己诏:关于备份的几个重要的点

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)

此条目发表在About, Glusterfs, Servuce分类目录,贴了, 标签。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注