误删 rpm 拯救事件 - 不小心 yum 卸载依赖程序引发的悲剧

目录

缘起

拯救过程

明确状况，制定方案

执行方案

经验总结

缘起

今日，按计划在一台云主机上安装一个 subversion 服务，将迁移过来的配置库重新搭建起来。
执行 yum install subversion 时，报了一个错误，sqlite 版本高，无法正常安装。
心想，这个简单，卸载一下重新装一个旧版本即可。
于是，yum remove sqlite
屏幕显示出一大串内容，没有仔细看，y

悲剧开始了...

当执行完毕再次调用 yum 装一个新版 sqlite 的时候，command not found...

再仔细看上方一大串内容，顿时出了一身冷汗...
kernel, openssh, rpm, sudo, yum 都被卸载了...

Removed:
  sqlite.x86_64 0:3.4.2-3                                                                                   

Dependency Removed:
  hmaccalc.x86_64 0:0.9.6-4.el5                      kernel.x86_64 0:2.6.18-164.11.1.el5                    
  man.x86_64 0:1.6d-3.el5                            mkinitrd.x86_64 0:5.1.19.6-82.el5                      
  nss.x86_64 0:3.21.3-2.el5_11                       openssh.x86_64 0:4.3p2-82.el5                          
  openssh-clients.x86_64 0:4.3p2-82.el5              openssh-server.x86_64 0:4.3p2-82.el5                   
  policycoreutils.x86_64 0:1.33.12-14.13.el5         python-sqlite.x86_64 0:1.1.7-1.2.1                     
  rpm.x86_64 0:4.4.2.3-36.el5_11                     rpm-libs.x86_64 0:4.4.2.3-36.el5_11                    
  rpm-python.x86_64 0:4.4.2.3-36.el5_11              sudo.x86_64 0:1.7.2p1-29.el5_10                        
  yum.noarch 0:3.2.22-40.el5.centos                  yum-fastestmirror.noarch 0:1.1.16-21.el5.centos        
  yum-metadata-parser.x86_64 0:1.1.2-4.el5          

Complete!

拯救过程

明确状况，制定方案

当前状况分析

1）当前连接正常可用
2）发起一个新连接，无法连上（当前可用连接千万不要断） - 因为 openssh 已经被卸载了...
3）其他已安装的服务还在正常运作，看来只要不重启，当前连接不断，还有直接恢复的机会
4）wget 可用，看来可以通过网络获取文件
5）后来过程中发现阿里云 ECS 提供了 web 版的远程连接工具，而且可以登录，看来是通过宿主机登录，甚好。只是字体太小，对于吾等眼神不太好的人实在是痛苦，故还是优先使用 xshell 的连接操作
6）因为是云服务虚拟机，无法通过光盘等方式恢复，初步考虑的可行方案是恢复命令程序或重装系统

备选方案

0）备份数据：趁还有一个会话连接能够访问，先把数据备份到另外一个数据盘上，即使最后系统挽救不回来，数据还在，花时间还是能够恢复的
1）活体拯救：不重启，利用当前会话所能使用的命令，将被删除的程序恢复回来。因目前rpm,yum 等安装程序都无法使用，可行方案有：
    1.1）通过源代码编译
    1.2）复制同版本操作系统内的文件
    1.2.1）先搜索 rpm，通过一个 web 服务中转文件，wget 到本地，逐层尝试恢复
    1.2.2）将 /usr/bin, /usr/etc, /usr/lib, /usr/lib64 目录下文件整体迁移（友人大S建议）
    1.2.x）实践中考虑到新部署的虚拟机使用的镜像不是标准版，故优先还是选择 1.2.1
    1.x）编译需要时间较长，优先选择了部署同一个版本的新操作系统，直接复制的方案。
2）涅槃重生：放弃当前操作系统，重装新系统并恢复所有服务及数据
    2.x）保留数据，重装操作系统。事实上本身有计划重装操作系统升级，但是计划是在把服务转移到另外环境后进行，当前并未做好准备。故此方案作为 方案1 无法执行后的保底方案
x）当前可用时间尚可，服务也未中断，故优先选择 1.2.1 方案，备选方案顺序为 1.2.2 => 1.1 => 2

执行方案

1）重新部署一个新的同版本操作系统的虚拟机，采用按量付费模式，用完即释放
2）采用方案 1.2.1 逐层恢复。这个过程比较需要耐心。这里最常用的命名就是 find / -name ***。遇到文件直接获取，遇到目录使用 tar zcvf 打包，获取后 tar zxvf 解压
3）经过大约一个多小时的处理，rpm 貌似恢复，但是感觉不够正常。 rpm help 可以显示帮助，直接使用 rpm 不显示帮助
4）下载几个核心的 rpm 包，尝试使用 rpm 安装... 执行后不报成功也不报失败，没有任何输出；也 find 不到新安装的文件，看来还是不能正常使用。转为使用 1.2.2
5）1.2.2 因为是有限几个目录整体打包，速度比较快；谨慎起见，在目标机上展开后，使用 cp a b -r -u 参数，减少提示内容，同时不覆盖已有文件，只复制原来不存在的文件，尽量减少文件不匹配的风险
6）一通操作后，rpm 可用，yum 还不太可行；使用 rpm 安装时，总有 conflict 导致无法安装，应该是有相关参数，但是比较困倦，头脑不大好用，故先尽力尝试恢复 yum
7）还是根据提示，使用 find 找到对应的文件，找到了 /usr/share/yum-cli；貌似就是这个，继续转移过来。大赞，yum 可用了
8）接下来就比较简单了，照着刚才卸载的列表，一气儿装回来。yum 安装还是方便，依赖关系、冲突处理都做好了，基本上只点 yes 就好了（此时可以开个电影放松一下了；千万记住 remove 的时候要小心，避免一个依赖关系导致一串应用都被卸载的惨案...）
9）其中 openssh 优先，万一连接断了，还能登录上；注意安装后 /etc/init.d/sshd start 启动服务，然后开一个新会话，确保可以正确连接后，就可以放心了，此时已不会失控
10）最后拯救完毕，服务都恢复了，最终多了一些冗余文件，暂时先不动了，后续计划是要重装升级的，到时冗余文件自然消失
11）释放临时服务，感谢 TA 为同伴提供了起死回生的关键部件；给计算机治病比人还是容易得多得多得多了，绝大多数零件（软硬件都算）还是可复制、可替换，唯一最要重视的是自身的独特数据；此刻向医生们致敬
12）睡醒一觉，做好记录和总结，希望能帮助到更多的伙伴

经验总结

1）在服务器上执行重要操作时，多开一个会话还是增加安全系数。此前一次服务器危机也是因为幸好开了一个 xftp 会话，活体替换系统库文件恢复了一个无法登录的系统...
2）数据备份重中之重，只要数据在，最最差的情况下还是可以重建服务
3）操作一定谨慎，重要提示要看清，警惕意识随时在，尤其在卸载、删除、覆盖命令和库文件等重要操作时，打起 10000% 的精神来
4）云服务商在安全恢复上还可以更进一步，帮助用户在紧急情况下拯救数字资产。本次体验的阿里云的在线远程登录就很好，这样即使无法 ssh 到服务器上，还是可以有一种控制手段进行补救处理。当然如果能在系统失控的情况下提供更底层的救援策略，那就更厉害了。再接再厉。
5）久练成精，出现问题不要紧张，冷静分析，做好方案，大部分问题都能解决；当然最好的办法还是“隐患险于明火，预防胜于救灾”