rm -rf 真是删库跑路的一把好手

前言

上回书说到《一个月黑风高的夜晚紧急完成gitlab服务器数据迁移》，因为数据迁移后原数据还是存在的，该分区硬盘快满了，进而影响了原目录下的日志存储，既然数据已经迁移到新的路径了，那原来的库直接删掉就好了，往往就是这么不经意间做了一个令人十分后怕的决定。

删库

说干就干，连上服务器就开始操作了，为了避免搞错了，我还打开了另一个ssh窗口，对照着正在使用的git库，来一步步查找原来路径下已经废弃的仓库，嗯，终于找到了，对比各种信息没啥问题，两个窗口相互对照，十分“保险”。

rm -rf xxx 走你，一切都安静了，好了退出当前路径检查一下空间大小，咦？路径怎么不对，好像删的是正在使用的那个库哎！服了，还真是受到了惊吓啊！背后发凉啊！gitlab网站访问一下，嗯，果然找不到了，拜拜！

跑路

既然库都删完了，要不跑路吧？

算了，能跑到哪呢？先回去看看能不能找回来吧~

恢复

rm -rf 恢复硬盘数据是别想了，一般会让你卸载硬盘，断网，防止擦除，用第三方工具等，这我之前都演练过，几乎没什么用，这个时候需要冷静，先理智的分析一下：

既然是git库，我本地也是有的，要不我把我的库推上去试试？虽然没有那么新，但也差不了几个提交了，不过远程库都被我删了，我如果推上去一个新库，别人是不是直接访问不了，或者引发冲突呢？

想起之前迁移的时候我还备份了数据目录呢，那这样，先把备份的数据恢复到误删除的目录下，然后我再找一个本地的拉取到了最新状态git库推上去，既然想清楚了，那就动手吧。

1. 通知相关人员先不要拉取和推送数据

2. 把一月前备份的git-data目录中对应数据通过 rsync 命令拷贝到误删除目录，这时通过gitlab网站已经能看到数据了，只是数据是一个月前的

3. 跳到版本发布机，上面的Git库数据是最新的，按照分支把版本发布机上的git数据逐个推送到gitlab服务器

4. 再次打开gitlab网站发现一切恢复如初，真是……

感想

rm -rf 命令真是删库跑路的一把好手，一点也不拖泥带水，更无回收站这个后悔药可以吃，所以在服务器上对文件使用了这个命令，基本上等于判了死刑，但是git库真是一个好东西，分布式的存储可以保证每个人那都有完整的仓库，只要能找到一个最新的就行。

为了保证我能有最新的库可以用，我赶紧在 jenkins 上新建了两个定时任务，每天定时把仓库拉取到最新，防止类似意外的发生。

后续

其实这个后续和删库这件事没有任何关系，如果非得说有什么关系，就是它们都属于“灾难”，删库刚刚处理完，紧接着游戏玩家出现登录不上的问题，一开始以为是网络波动，因为我登录过程也不太顺畅，直到玩家发来了录屏，我才发现这个问题又有的查了。

玩家所说的无法登录并不是真的登不进去，而是登录之后加载完读条刚要进场景，直接退到登录界面，查询网络消息发现每次登录后几秒钟，网络连接自动断开，但是断开前的通讯流程日志显示的延迟信息，又说明网络状况良好，一头雾水。

最后耗时两天，在收集了各种线索以后，发现是升级Unity版本后，在法语、俄语、乌克兰语作为系统语言时，对c#的字符串处理逻辑要求更加严格，如果不做处理沿用之前的写法，很容易出现崩溃错误，因为有try-catch处理，表现出来就是直接断网会登录界面，统一设置语言处理函数时修复了此问题。

身心俱疲~

总结

• 使用 rm -rf 命令还是要谨慎，谨慎，再谨慎
• 如果真的删库了，也不一定非得跑路，先冷静想想有没有补救的措施
• 语言、字符集、编码真的是相互纠结，至此我的bug库里又收录了系统语言运行时，神奇

---

==>> 反爬链接，请勿点击，原地爆炸，概不负责！<<==

---

北风卷地白草折，胡天八月即飞雪~