ESXi上面虚拟机磁盘损坏修复案例

事故情况

最近同事反馈, 一个文件更新后出现了文件部分不可读的情况
具体现象为: 前端功能打开白屏
后端文件 前面93行不显示, notepad++打开都是 NULL 黑框.
然后重新覆盖文件, 有概率成功, 有概率失败. 
遇到问题之后进行了紧急处理. 但是一开始的路线不太正确.
所以本次想总结一下问题解决过程. 

遇到的第一个问题

最开始怀疑是宿主机的磁盘出现了坏块
然后迁移了虚拟机的宿主机.
因为时间较久, 只能第二天早上进行处理

第二天机器处理完成之后进行了启动等处理发现没有问题. 
但是为了保险起见, 就准备复制整个应用目录, 进行备份
但是发现复制过程中 会出现
bash input/output error
然后所有的功能都会出现这个提示信息 , 系统几乎不可用
只能硬重启. 

遇到的第二个问题

因为第一个问题时进行了虚拟机迁移
可以排除是物理机器磁盘损坏的问题.
怀疑是否是 文件 损坏导致的

当然这个怀疑比较幼稚, 我删除了复制失败的目录
然后从其他环境复制复制失败的目录(前端文件, 无状态,可以复制)
本以为复制完成就可以万事大吉
但是基于测试要全面的考虑, 我再次进行了整个应用程序目录的复制
很不幸, 整个环境再次出现 input/output error
此时基本确定是 linux 虚拟机的文件系统出现了损坏. 

解决文件系统损坏-尝试1

文件系统损坏,可能无法在一个使用着的系统进行, 需要进入rescue 救援模式进行.
1. 重启系统后，进入grup引导页面，选中第一项然后按“e” 进入编辑模式：
2. 通过↓键找到linux16开头行,如所示“ro”处(ro表示只读),
  将ro替换为rw init=/sysroot/bin/sh，然后按ctrl+x 系统重启进入救援模式
3. chroot /sysroot 获取root权限

但是发现这种方式也不行

解决文件系统损坏-尝试2

修改虚拟机的配置 BIOS 设置为 CD-ROM启动
修改虚拟机的配置 在设置界面增加上 CentOS的IOS系统影像
重启机器.进入第一个界面, 选择troubleshooting
然后选择rescue a CentOS system
进入一个选择 输入 1 continue
执行命令 chroot /mnt/sysimage
执行df -Th 查看磁盘情况
查看最全的文件系统路径
执行 umount -lf /dev/mapper/centos-root
执行完之后需要 退出到上一层界面
exit
执行 xfs_repair /dev/mapper/centos-root
注意这一步可能会比较旧. 需要修复. 
执行完成之后 关机机器. 卸载 iso 重新启动. 

验证文件系统问题是否解决

time scp -r /app /appback
验证是否还会出现严重问题. 

很早之前Oracle数据库取动失败曾经使用过这个方法.
这是第一次遇到文件系统导致应用出问题的.
感觉必须要有足够的技术储备.不然容易临时抓瞎.