一、修复文件系统挂载异常故障
1.1、故障情况
系统启动没有正常进入系统里面，而是进入紧急模式(You are in emergency mode)，如下图所示：
1.2、故障分析
当系统显示进入紧急模式时，可执行如下步骤分析定位问题：
《1》可以先重启系统查看系统的启动日志了解更多的细节（即在系统启动且倒计时结束后，可按下【f1】键了解启动日志详情）；
《2》接着我们输入root用户的密码进入系统中查看持久化【/etc/fstab】中的挂载分区内容；
《3》接着再执行【blkid】可以看到系统当前所有可用的分区UUID信息；
《4》接着在查看本机的所有磁盘情况【parted -l】可以看到有两块磁盘【/dev/sda】【/dev/sdb】两者对照就可以判断出是这个【/dev/sdb】的磁盘出问题了，系统的分区内容都是正常的（既然系统是正常的，那么我们可以先将有问题的/data2对应的持久化内容先注释【vi /etc/fstab】并重启【reboot】；
《5》重启正常进入系统后尝试挂载这个有问题的磁盘【/dev/sdb】显示"文件系统类型错误、选项错误、/dev/sdb 上有坏超级块、缺少代码页或帮助程序或其他错误."也就是说这个磁盘出问题了，还有就是使用【parted -l】查看所有磁盘信息时分区表显示【unknown】时，考虑到该磁盘有数据内容，不能随意格式化，那么我们可以尝试修复该磁盘看看），如下图所示：
1.3、修复故障
根据查看到的故障磁盘分区是xfs文件系统的，因此可以尝试使用【xfs_repair /dev/sdb】修复。而ext4文件系统则使用【fsck -y /dev/sdb】命令修复（一般来说执行修复命令后大部分都可以修复成功后挂载上即可。但是也有修复不成功的情况，可先使用【Testdisk】修复分区（若恢复后数都有，但数据名称显示不对，可以使用rlinux进行恢复数据），最后就需要使用数据恢复工具尝试恢复数据了）。
bash
#下载testdisk工具来尝试修复故障磁盘分区
wget https://www.cgsecurity.org/testdisk-7.2.linux26-x86_64.tar.bz2
tar -jxvf testdisk-7.2.linux26-x86_64.tar.bz2
cd testdisk-7.2/
./testdisk_static 
到这里恭喜你，磁盘的文件系统异常故障修复完成。
1.4、模拟故障
bash
#模拟文件系统挂载异常故障
#1-给系统添加一个独立的磁盘（如:/dev/sdb）
#2-将这个新添加的独立磁盘分区并格式化为xfs文件系统
parted -l
parted /dev/sdb
mklabel gpt
mkpart primary 0gb 10gb
p
q
mkfs.xfs /dev/sdb1
#3-挂载磁盘分区并写入数据
mkdir /data2
mount /dev/sdb1 /data2
#3-分区格式化完成后，不挂载（首先清除磁盘主引导记录（MBR））
dd if=/dev/zero of=/dev/sdb bs=512 count=1
#4-将/dev/sdb分区自动挂载添加到【/etc/fstab】文件中
blkid /dev/sdb1
vi /etc/fstab
UUID=77cbb9a9-4064-4851-8706-e85f42778876 /data2 xfs defaults 0 0|--------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 序号 | 说明 |
| 1 | MBR（主引导记录）是磁盘第一个扇区（512 字节）的关键数据，包含： * 446 字节：引导程序 * 64 字节：分区表（最多记录 4 个主分区） * 2 字节：分区表结束标志（0x55AA） |
| 2 | 执行【dd if=/dev/zero of=/dev/sdb bs=512 count=1】清除主引导记录命令后，整个 MBR 扇区会被 0 覆盖，最终效果 ： 1. 磁盘的分区表被彻底清空（无法识别原有分区）； 2. 引导程序被清除（磁盘无法引导系统）； 3. 仅擦除第一个扇区，磁盘后续数据仍保留（但分区表丢失后无法直接访问）。 |
| 3 | 清除主引导记录（MBR）的典型场景： 1、清空旧磁盘的分区表（ 当磁盘原有分区表混乱、或想重新规划分区（如从 MBR 转 GPT）时，先清除 MBR 再重新分区）。 2、彻底初始化磁盘（即：给所有扇区都写0，极其耗时，请勿用于大容量磁盘（但速度极慢，慎用） 【如： bash dd if=/dev/zero of=/dev/sdb bs=10M ） |
[清除主引导记录（MBR）相关补充说明]
二、修复自动挂载文件丢失故障
1.1、故障情况
系统启动没有正常进入系统里面，而是卡在一个灰色界面，在按下【f1】键后显示"
Starting Switch Root...
systemd-journald[254]: Faild to send WATCHDOG=1 notification message: Connection refused
systemd-journald[254]: Faild to send WATCHDOG=1 notification message: Transport endpoint is not connected "
1.2、故障分析
既然系统无法正常启动，一直卡住，没办法进一步分析操作；那么就借助系统盘（或系统用启动U盘且配有该系统的系统镜像）来进入系统救援模式【在主机上插入系统启动U盘，并将U盘设置为第一启动项后启动，选择【Troubleshooting】按下Enter键后-->选择【Rescue a openEuler system】按下Enter键即准备进入系统救援模式-->【输入1】后按下Enter键以读写方式进入系统救援模式】。
进入系统救援模式后就可以看到一个提示"（You don't have any Linux partitions）你没有任何Linux分区"的错误，则执行如下操作进行分析：
《1》执行【parted -l】查看系统所有的磁盘及其分区情况。
《2》执行【blkid】查看系统所有可用的分区信息（包含分区的UUID及其文件系统类型【在这里其实可以确定/boot/efi与swap】）。
《3》执行【tune2fs -l /dev/sdbx】命令可以分别确定其他的挂载分区。
1.3、修复故障
现在找到了所有的分区的UUID、文件类型、还有对应挂载的分区，就可以构建持久化的【/etc/fstab】文件了。
bash
#构建持久化【/etc/fstab】挂载分区文件步骤
#1-先将根分区(如：/dev/sda5)临时挂载到【/mnt】上
#2-进入这个临时挂载的【/mnt】下创建【/etc/fstab】文件
df -hT
mount /dev/sda5 /mnt
vi etc/fstab
#3-【/etc/fstab】文件内容
UUID=76A5-E83D /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=367145aa-2fcf-4f97-a43f-8bd859a3a1e7 /boot ext4 defaults 1 2
UUID=aa268be9-a47a-40a2-a627-a94bab2dcd2c /usr ext4 defaults 1 2
UUID=8e02b5d3-3d89-4f5f-adb9-603d8be0a37f /var ext4 defaults 1 2
UUID=9571836f-aeb0-4646-961d-d5f565435a14 / ext4 defaults 1 1
UUID=2617a1d1-8202-403b-b35d-08313c1929c2 none swap defaults 0 0
UUID=870fd321-3027-43ff-a5ff-29c4d1f744aa /data ext4 defaults 1 2
|--------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 序号 | /etc/fstab文件内容示例【UUID=367145aa-2fcf-4f97-a43f-8bd859a3a1e7 /boot ext4 defaults 1 2】 |
| 1 | UUID是挂载分区的唯一标识 |
| 2 | /boot是挂载的分区名称 |
| 3 | ext4是文件系统格式 |
| 4 | defaults是挂载选项 |
| 5 | 是dump 值，用于告诉 dump 工具（系统备份工具）是否需要备份该文件系统： * 0：默认值 ，表示该文件系统不需要被 dump 备份； * 1：表示该文件系统需要被 dump 定期备份。 根分区（/）、数据分区（/data）这些核心数据分区建议备份，设置为1。 临时分区（/tmp）、挂载的 U 盘 / 网络盘，这些临时 / 非核心数据无需备份，设置为0。 绝大多数普通场景，这些现代系统很少用 dump，默认 0 即可。 |
| 6 | 是 fsck 值，用于指定系统启动时 fsck 工具检查文件系统： * 0：表示该文件系统不需要被 fsck 检查； * 1：最高优先级，仅用于根分区（/）（系统启动时最先检查根分区）； * 2：次优先级，用于其他本地文件系统（如 /home、/data 等）； * ≥3：一般不用，仅特殊场景（如多个次要分区的细分优先级）。 根分区（/）是唯一的最高优先级，设置为1； 本地数据分区（/home、/var 等），根分区检查完后检查，设置为2； 临时分区（/tmp）、U 盘、网络盘，无需检查（或无法检查），设置为0； swap 分区，无文件系统，无需检查，设置为0。 |
[持久化分区挂载文件【/etc/fstab】内容解析]
1.4、模拟故障
bash
#手动模拟自动挂载文件丢失故障
#1-在虚拟机里面创建一个Linux系统（如：OpenEuler）
#2-进入Linux系统中将持久化自动挂载文件【/etc/fstab】删除
rm -rf /etc/fstab
#3-重启系统
reboot
三、修复系统进程CPU占用率过高故障
1.1、故障情况
使用【top】命令查看系统的占用率，发现前四个进程的CPU使用率都高达98%及其以上，如下图所示：
1.2、故障分析
看到顶部右侧的CPU负载已经接近CPU核心数，那么接下来就是观察详细系统占用率，可以看到前四个进程中的CPU的占用率已经高达98%及其以上，此时我们应该排查这四个占用CPU较高的进程是对应哪个文件后执行如下操作：
bash
#通过进程PID获取到对应的文件(如：/var/tmp/.../sysupdate)
ll /proc/PID/exe
#2-直接删除获取到的文件（若root用户删除文件提示"无法删除xxx不允许的操作"，则需要检查这个文件是不是被加锁了，将锁去掉）
rm -rf /var/tmp/.../sysupdate
#2.1-查看指定文件是否被加锁了
lsattr /var/tmp/.../sysupdate
#2.2-将指定文件解锁
chattr -i /var/tmp/.../sysupdate
rm -rf /var/tmp/.../sysupdate
#2.3-进入到这个指定目录下查看所有文件内容
cd /var/tmp/.../
ll -a
#2.4-删除这个目录下的所有文件
rm -rf ./*
#3-将异常进程全部强制删除
killall -9 sysupdate
#4-再次执行【top】命令查看这个异常命令的进程是否还会生成（若还生成则需要查看所有定时任务）
#5-查看所有定时任务文件内容排查异常内容
cat /etc/crontab
crontab -l
ll -a /var/spool/cron/
ll -a /etc/cron.d
#在【/etc/cron.d】的两个定时文件中发现异常，每分钟都在定时执行任务【接下来就是先将两个定时文件中的异常定时任务注释；然后删除定时任务定时启动的文件；最后将所有的异常进程强制杀死】线上Linux服务器被植入各种病毒的详细分析、处理、加固流程
https://coffeemilk.blog.csdn.net/article/details/150275961
1.3、修复故障
在【/etc/cron.d】的两个定时文件中发现异常，每分钟都在定时执行任务【接下来就是先将两个定时文件中的异常定时任务注释；然后删除定时任务定时启动的文件；最后将所有的异常进程强制杀死后再次执行【top】命令后监测系统占用率一段时间是否正常】。
1.4、分析异常定时任务产生的原因并防范加固
Linux服务器常见的攻击类型及其对应的防御策略和被攻击后的处理思路https://coffeemilk.blog.csdn.net/article/details/150221129 通过分析日志后了解到是由于服务器上安装了redis-server提供给外网使用，且没有对redis-server服务设置密码，也就是说任何人都可以直接操作这个redis-server，是黑客扫描端口后控制了redis-server接着通过redis-server的漏洞植入了病毒导致【接下来就是给redis-server程序设置复杂密码，并在防火墙设置只访问白名单】。
