备份能解压不等于能恢复：给博客设计一次恢复演练 我现在已经有自动备份，但备份脚本返回成功，只能证明完成了某些检查。真正出故障时能否恢复，还需要单独验证。这篇是我根据实战笔记整理的演练方案，不把计划写成已经完成的恢复成绩。

磁盘空间不足时，先用 df、du、lsof 定位 看到“设备上没有空间”时，先确认是哪个挂载点满了，再定位增长最快的目录。不要从根目录开始盲删文件：日志、数据库和仍被进程占用的已删除文件，处理方式完全不同。第一步：确定哪个文件系统满了df -hT df -idf -hT 看容量与文件系统类型；df -i 看 inode。若容量还有剩余但 inode 已耗尽，通常是小文件数量过多，此时删除一个大文件没有帮助。第二步：缩小范围sudo du -xhd1 /var 2>/dev/null | sort -h sudo du -xhd1 /home 2>/dev/null | sort -h-x 限制在同一文件系统，-d1 只看一层目录。逐层进入占用最大的目录，确认文件用途和保留要求。sort -h 按人类可读的容量排序。第三步：解释 df 与 du 不一致若 df 显示占用很高，du 却找不到对应文件，可以检查是否有进程仍打开了已删除文件：sudo lsof +L1这类空间通常要等占用文件的进程正常关闭后才会释放。先确认进程和业务影响，再选择合适的重启窗口；不要直接强杀未知进程。复盘模板记下告警时间、满的挂载点、df 与 du 的关键数字、找到的目录或进程、处理动作，以及处理后的 df -hT 输出。这样下次空间上涨时，能分辨是正常增长还是重复故障。不要忽略挂载点与测量误差df 和 du 不一致还可能来自文件系统元数据、保留块、快照、挂载覆盖或扫描时文件持续变化，已删除但仍打开的文件只是其中一种原因。du 扫描大目录会产生 I/O，先缩小范围；2>/dev/null 会隐藏权限等错误，排查异常时应去掉重定向。确认容量与 inode 的问题分别处理，数据库数据文件不能当普通缓存删除。内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。