2022/01/13 晚
备份的重要性
事故发生
今天下午在 push 代码时，突然发现代码 push 不上去，打开 gitlab 一看，代码仓库居然变成了十月份的样子。赶紧给网管说了这个现象。
网管一看 Gitlab 就发现大事不妙，赶紧打开 Astack 后台，准备恢复 gitlab 服务器的快照（写了定时任务每天对服务器做快照）。打开服务器快照仓库一看，这下真的凉了——快照仓库只剩下十月份的快照了。
解决方案
网管赶紧把这个问题汇报给了领导，领导气得直说：“这他妈不是扯淡呢吗？竟然会出现这种问题！！这个属于是重大生产事故了！！！”。既然事情已经发生了那就只能想解决办法了，于是乎领导紧急召开了会议，做了如下安排：
- 将当前虚拟机做打包备份迁移，不能将最后这点数据也丢失了；
- 对 gitlab 数据进行备份迁移，确保当前仓库数据能够保留；
- 上面的步骤做完保证当前留存的数据保存完善后再查找故障原因，查看到底是什么问题导致的此次事故；
- 查看各代码仓库本地缓存数据，统计最坏损失情况。
会议开完后大家就开始忙活了。。。
忙活了一下午现在已经完成了部分：
- 统计了代码仓库损失，有两个文档仓库本地没有缓存，其余的代码仓库本地都有完整数据；
- gitlab 和 当前虚拟机都已经打包并保证当前数据完整保留了；
- 查找到了事故原因。
事故原因
经过排查发现是网管创建的快照任务的问题：
- 每日快照备份的任务在十月份时就已经出了问题，但是一直没有去管这个问题；
- 今天有人直接对物理主机进行了关电操作，云平台检测到异常于是选择对虚拟机进行恢复上一次快照处理；
- 仓库里面只有十月份的快照，于是虚拟机恢复到了十月份的状态。
反思
本次事故仅仅只是我们组内的仓库出现了问题，大家本地也都还有代码仓库数据，因此造成的影响不大。但是我们必须对本次事故进行反思，防止下一次再出现此次状况：
- 重要数据及时做好备份，备份手段不能单一化，备份存储地点不能单一化，应当保证备份数据的安全；
- 定期检查备份安全状况，不能完全依赖于自动化程序，重要数据应当手动确认；
- 机房属于极为重要的地方，任何人员的操作都应当被记录，否则会出现事故时无法进行追责处理；
- 快照不应当作为数据备份的方式；
- 数据丢失后，应当首先保护现场，保证当前状态备份完成再进行处理，防止二次破坏；
- 事故发生后第一时间应当做周密的安排对事故进行处理，在对事故处理好后再考虑追责等事情。