就在前2天，9月1日接到用户电话说his卡住，自己硬件重启了下，造成启动启动后，直接进入救援模式，之后我一系列的操作，还是没有弄起来，看实在不行了，虽然是帮忙，这么干会出问题的，不可能业务系统停机这么长时间，最后建议先备份Oracle 数据库，随后恢复数据和修复系统同时并进，看看谁先搞好。
事情就是这么进展，下午1点半，我把机器进入紧急救援模式，开始挂载移动磁盘备份数据，想着用户快点备份数据，赶紧恢复系统业务，哪成想，备份391G表空间数据，花了近7个小时，一直到晚上20点，哎，想想这个时候这么办，还这样下去吗？
用户急了，发出英雄贴，看看其他高手可能解决，果不其然，高手出现了，我发现的磁盘分区/dev/mapper/centos-root的损坏，而那兄弟不仅不慢的上来发现是/dev/mapper/centos-var 报错，在救援模式下，mount -a 报 /dev/mapper/centos-var无法挂载，就这样通过修复的手段修复了。事后我复盘，发现自己离一线太久了，同时缺乏对相关知识的关联思考欠缺。
下面我们来分析下：
1、单用户和救援模式？
2、磁盘文件系统修复在什么条件下执行？
3、找准错误日志，具体确定故障类型，最短时间恢复业务系统？
情况介绍：
1、操作系统 centos 7.9 x64
2、数据库： Oracle 11g 11.2.0.4 for Linux
3、磁盘格式：xfs日志文件系统
下面解释下第一问题：单用户模式和救援模式
1、单用户模式
可以对系统进行修复，如改密码，修复启动项，修复账户锁定，修改不正确的系统配置导致系统无法启动的配置；
特征：系统下的磁盘分区是可以加载的，可读写各分区上的数据，从启动的过程中添加的参数和mount -a 磁盘空间
就可以看出来。
单用户进入方法：
启动linux操作系统，按e 进入可编辑界面，在linux16 后面 ro 处和最后段 写入字符 rw init=/bin/sh ，按ctrl+x 直接
进入单用户模式，如图
备注：在编辑的过程中，把ro变成rw 这就意味着系统启动后，无须在敲上 “mount -o remount, rw / “的
语句，此过程中操作系统的哪个分区异常，即使在单用户模式下，也是无法进入的，也会出现报错。此种
情况下，Linux救援模式派上用场了。
当然，在开启selinux的模式下，对系统进行了修改，则需要运行命令”touch /.autorelabel” ,否则
系统可能无法正常启动了。
第二个问题：Linux救援模式
救援模式就是从物理介质方式启动，从而获得一个runlevel，如果按照流程会进入一个单用户模式，因
为不需要从硬盘启动，可以将硬盘中的系统以文件方式挂载，可以从安装介质中获取硬盘系统中受损丢失文件
或者将重要数据拷贝出来。
根据提示，硬盘上的系统已经挂载到/mnt/sysimage目录下，需要原系统的root用户执行chroot /mnt/sysimage
未执行chroot /mnt/sysimage时的根目录文件是启动盘上的，只读。
在此种模式下改密码，必须要切换到系统硬盘的目录chroot /mnt/sysimage
还可以不切换系统：直接修改 /etc/sysimage/etc/passwd 将root中第二列 X信息删除，保存退出，重启后，不需要
root密码也可进入系统，重新设置密码即可。
总结： 1、单用户模式是在grub2引导时编辑内核引导，可以使用只读或可写的方式挂载系统，一般用于简单的修复系统；
2、救援模式，在光盘介质参与的情况下进行的修复，其实也是进入单用户模式，需要切换目录，加载本地磁盘数据，其实
救援模式也是一种单用户，使用的方式不一样。
本案例中，系统启动直接进入救援模式，可以肯定文件都是只读的，无法修改，可以加载正常的磁盘分区，如果不正常也能
进入该模式，但是使用mount -a的情况下，会出现报错，这是我们可以根据磁盘的损坏程度进行修复。 如果是ext4等文件系统可以使用fsck /dev/mapper/centos-var 方式来修复； 如果是xfs文件系统，一般修复 可以使用xfs_repair /dev/mapper/centos-var修复，如果修复出现报错，那么可以使用xfs_repair -L /dev/mapper/centos-var 可能数据有损坏，造成数据丢失。
案例处理过程中，注意日志报错的情况，找到报错的关键点，才能使问题迎刃而解，最后，分析现场严重情况，备份数据很重要！！！
