5 个必学的 Linux 命令，能救你一命！

在 Linux 系统运维中，总会遇到 “系统卡死、文件误删、磁盘满爆、日志报错找不到原因” 等紧急情况 —— 此时选对命令，能快速止损甚至挽回数据。以下 5 个命令，覆盖日志排查、文件系统修复、数据恢复、进程急救、磁盘释放五大核心应急场景，学会就能应对 80% 的 “救命” 时刻。

1. journalctl：10 秒定位系统 “致命报错”

救命场景

系统突然无法启动、服务崩溃（如 SSH 连不上、数据库启动失败），却不知道哪里出问题 —— 此时journalctl能快速提取 “紧急日志”，定位故障根源（如配置错误、依赖缺失、硬件报错）。

命令作用

Linux 系统日志默认由journald服务管理，journalctl是其命令行工具，可按 “日志级别、时间、服务名” 筛选日志，尤其适合紧急情况下快速定位致命错误（如内核崩溃、权限不足、文件损坏）。

核心用法 + 应急实例

场景 1：系统启动失败，查看 “紧急级” 日志

# 只显示紧急/致命级别的日志（优先级最高，直接关联系统崩溃）

journalctl --prio=emerg --no-pager

# –prio=emerg：筛选紧急日志（级别：emerg > alert > crit > err > warn > info > debug）

# –no-pager：直接输出结果，避免翻页卡顿（应急时省时间）

实例效果：若输出 “Failed to mount /home: Invalid argument”，说明/home分区挂载失败，大概率是文件系统损坏，需用fsck修复（见第 2 个命令）。

场景 2：SSH 服务突然连不上，查看 SSH 服务日志

# 查看sshd服务的最近100条错误日志，按时间倒序（最新的在最下面）

journalctl -u sshd -e -n 100 --no-pager

# -u sshd：指定服务名（sshd为SSH服务）

# -e：直接跳转到日志末尾（最新日志）

# -n 100：只显示最近100条，避免日志过多卡顿

实例效果：若输出 “sshd: Permissions 0644 for ‘/etc/ssh/ssh_host_rsa_key’ are too open”，说明 SSH 密钥文件权限过松，执行chmod 600 /etc/ssh/ssh_host_rsa_key即可修复。

注意事项

若系统日志过大，添加–since “10 minutes ago”只看最近 10 分钟日志，加快查询速度。

非系统级日志（如应用日志）需看对应路径（如/var/log/nginx/error.log），但journalctl优先解决 “系统级故障”。

2. fsck：文件系统损坏时 “抢救分区”

救命场景

系统启动时提示 “fs error: unable to mount /dev/sda1”（分区挂载失败），或执行ls时提示 “Input/output error”—— 这是文件系统损坏的典型症状，若不修复，分区可能无法使用，数据面临丢失，fsck能直接修复多数文件系统错误。

命令作用

fsck（File System Check）是 Linux 自带的文件系统修复工具，支持 ext2/ext3/ext4、xfs 等主流文件系统，能修复 “超级块损坏、inode 错误、坏道标记” 等常见问题，是分区 “救砖” 的核心命令。

核心用法 + 应急实例

场景：/home分区（/dev/mapper/cl-home）挂载失败，修复文件系统

# 1. 先卸载损坏的分区（必须卸载！挂载时修复会损坏数据）

umount /home

# 若提示“device is busy”（设备被占用），先杀占用进程：fuser -m -k /home

# 2. 执行fsck修复（ext4文件系统用fsck.ext4，xfs用xfs_repair）

fsck.ext4 /dev/mapper/cl-home

# 或通用写法（自动识别文件系统）：fsck /dev/mapper/cl-home

# 3. 修复过程中会提示“fix? y/n”，输入y确认修复（一路按y即可）

# 4. 修复完成后重新挂载分区

mount /home

# 5. 验证：执行ls /home，能正常显示文件说明修复成功

ls /home

关键参数：

-y：自动确认所有修复操作（无需手动按 y，适合批量修复或远程操作），如fsck.ext4 -y /dev/mapper/cl-home。

-f：强制修复（即使文件系统看起来正常，也强制检查，适合怀疑有隐藏错误时）。

注意事项

xfs 文件系统特殊：不能用fsck，需用xfs_repair，命令：xfs_repair /dev/sda1（同样需先卸载）。

若修复后仍报错，可能是硬件坏道，需用badblocks /dev/sda1检测坏道，再用fsck标记坏道避免使用。

3. extundelete：误删文件后 “紧急恢复”

救命场景

执行rm -rf /home/user/important.txt后瞬间后悔，或误删项目代码、数据库备份文件 —— 只要文件系统是 ext3/ext4（多数 Linux 默认），且删除后没有写入新数据（避免覆盖），extundelete能快速恢复误删文件，堪称 “Linux 数据急救神器”。

命令作用

extundelete是针对 ext3/ext4 文件系统的开源数据恢复工具，通过分析 inode 和日志，找回被rm删除但未被覆盖的文件，支持恢复单个文件、目录甚至整个分区的文件。

核心用法 + 应急实例

场景：误删/home/user/important.txt（位于 /dev/sda1 分区），紧急恢复

# 1. 先卸载分区（避免新数据写入覆盖删除的文件，这是恢复成功的关键！）

umount /home # 若/dev/sda1挂载在/home

# 2. 安装extundelete（不同发行版安装命令）

# RHEL/CentOS：先装EPEL源，再安装

yum install -y epel-release

yum install -y extundelete

# Debian/Ubuntu：直接安装

apt install -y extundelete

# 3. 查看可恢复的文件列表（确认要恢复的文件是否存在）

extundelete /dev/sda1 --list-all

# 或指定路径查看：extundelete /dev/sda1 –restore-file /home/user/important.txt

# 4. 恢复单个文件（恢复到当前目录的RECOVERED_FILES文件夹下）

extundelete /dev/sda1 --restore-file /home/user/important.txt

# 5. 恢复整个目录（如恢复/home/user/docs目录）

# extundelete /dev/sda1 –restore-directory /home/user/docs

# 6. 查看恢复的文件（恢复后的文件在RECOVERED_FILES目录下）

ls ./RECOVERED_FILES/home/user/

# 7. 将恢复的文件移回原路径

mv ./RECOVERED_FILES/home/user/important.txt /home/user/

注意事项

恢复前提：

1. 文件系统必须是 ext3/ext4（xfs 文件系统需用xfs_restore，但需提前有快照，应急场景下不如 extundelete 实用）。

1. 删除后禁止写入新数据（如不要新建文件、不要安装软件、不要重启服务），否则被覆盖后无法恢复。

若误删根分区文件，无法卸载根分区，需用 Live CD（如 CentOS 安装盘）启动系统，再挂载分区恢复。

4. top：系统卡死时 “揪出元凶”

救命场景

系统突然卡顿、SSH 连接超时、鼠标键盘无响应，或ping通但无法操作 —— 此时top能实时查看进程 CPU、内存占用，快速定位 “吃满资源” 的异常进程（如挖矿程序、死循环脚本），杀死后即可恢复系统正常运行。

命令作用

top是 Linux 默认的进程监控工具，实时显示进程的 CPU 使用率、内存占用、PID（进程 ID）等信息，支持按资源占用排序，能快速识别并终止异常进程，是系统 “抗卡死” 的必备命令。

核心用法 + 应急实例

场景：系统 CPU 使用率 100%，卡顿严重，定位并杀死异常进程

# 1. 执行top命令，进入实时监控界面

top

# 2. 按P键（大写），按CPU使用率从高到低排序（顶部进程即为“元凶”）

# 按M键（大写），按内存使用率排序（适合内存爆满场景）

# 3. 查看异常进程：比如看到“minerd”（挖矿程序）CPU占用99%，PID为12345

# 4. 杀死异常进程（按q键退出top，或在top界面直接按k键）

# 方法1：在top界面按k键，输入PID（如12345），按回车确认杀死

# 方法2：退出top后执行kill命令（强制杀死用-9参数）

kill -9 12345

# 5. 验证：再次执行top，查看CPU使用率是否下降到正常范围（如<50%）

top

top 界面关键指标解读：

%Cpu(s)：总 CPU 使用率，us（用户进程占用）过高是应用问题，sy（系统进程占用）过高可能是内核或驱动问题。

%MEM：进程内存使用率，若某进程内存占用持续增长，可能是内存泄漏，需重启服务或杀死。

进阶技巧

用htop替代top（需安装），界面更直观，支持鼠标操作，命令：htop（用法与 top 类似，更适合新手）。

若进程反复被拉起（杀死后又重启），需查进程父 ID（ps -ef | grep 12345），杀死父进程或禁用对应的服务（如systemctl disable –now minerd）。

5. du：磁盘满爆时 “1 分钟释放空间”

救命场景

系统提示 “No space left on device”（磁盘空间不足），导致无法新建文件、日志无法写入、服务启动失败 —— 此时du能快速找出 “吃满磁盘” 的大文件 / 目录，删除无用文件（如旧日志、临时文件）释放空间，让系统恢复正常。

命令作用

du（Disk Usage）用于查看文件 / 目录的磁盘占用大小，配合排序命令（sort），能快速定位占用空间最大的文件，是磁盘满应急时 “清理空间” 的核心工具。

核心用法 + 应急实例

场景：/ 分区（/dev/sda2）满了，找出大文件并清理

# 1. 先查看各分区占用情况，确认满了的分区（如/dev/sda2的Use%为100%）

df -h

# 2. 进入满了的分区（如/分区），查找所有目录的占用大小（按从大到小排序）

cd /

du -sh /* | sort -rh

# -sh：-s显示总大小，-h人性化单位（如GB、MB）

# sort -rh：-r反向排序（从大到小），-h按人性化单位排序

# 3. 定位大目录：比如看到/var占用50GB（正常应为几GB），进入/var继续查找

cd /var

du -sh /* | sort -rh

# 4. 发现/var/log占用45GB（旧日志过多），清理30天前的日志文件

find /var/log -name "*.log" -mtime +30 -delete

# -mtime +30：修改时间在30天前的文件

# -delete：直接删除（谨慎使用，建议先执行find /var/log -name “*.log” -mtime +30查看要删除的文件）

# 5. 还可删除临时文件（/tmp目录下超过7天的文件）

find /tmp -type f -mtime +7 -delete

# 6. 验证：执行df -h，查看磁盘占用是否下降（如Use%从100%降到60%）

df -h

应急清理优先级：

优先删日志文件（/var/log/*.log）：占用大且多为非关键历史记录。

次选删临时文件（/tmp、/var/tmp）：重启后会自动清空，安全无风险。

最后删无用安装包（yum clean all或apt clean）：释放软件缓存空间。

注意事项

不要轻易删除/bin、/lib、/usr下的文件（系统核心文件），误删会导致系统崩溃。

若大文件是数据库文件（如 MySQL 的 ibdata1），不要直接删除，需通过数据库工具清理冗余数据（如删除旧表、归档数据）。

应急小贴士

提前备份：以上命令虽能 “救命”，但最好的应急是 “避免应急”—— 定期用rsync备份关键数据（如rsync -av /home /backup），开启定时任务（crontab）自动备份。

操作前确认：执行fsck、rm、kill等命令前，务必确认设备名（如/dev/sda1）、PID、文件路径，避免误操作导致更大损失。

记录日志：应急操作后，用history > /var/log/emergency_$(date +%Y%m%d).log保存命令历史，方便后续复盘故障原因。

掌握这 5 个命令，就能在 Linux 系统突发故障时快速响应，避免小问题演变成 “数据丢失、系统崩溃” 的大灾难！