Linux存储故障恢复核心是立即只读、先查硬件再查文件系统；extundelete适用于ext3/ext4误删但需卸载分区；TestDisk修复分区表，PhotoRec按签名恢复文件；所有操作目标路径必须为另一物理盘；LiveCD是根分区崩溃唯一安全入口；恢复后必须验证文件完整性。

Linux 存储故障不是“能不能恢复”，而是“恢复多少、快不快、有没有踩坑”。核心原则只有一条：停止写入，立即只读操作——任何后续命令，都必须建立在这个前提上。

确认磁盘状态：先看硬件，再看文件系统

很多“数据丢失”其实是硬件先行告警。别急着跑 extundelete，先确认底层是否可信。

• 用 smartctl -a /dev/sdX 查 SMART 状态，重点关注 Reallocated_Sector_Ct、Current_Pending_Sector 和 UDMA_CRC_Error_Count —— 有非零值且持续增长，说明硬盘正在失效，立刻停机换盘，别在坏盘上做任何恢复尝试
• 运行 dmesg | grep -i "ata\|nvme\|error\|fail"，抓取内核级 I/O 错误。出现 end_request: I/O error 或 timeout waiting for device，基本可判定是物理链路或固件问题
• 如果硬件无异常，再检查文件系统挂载状态：mount | grep "/dev/sdX"。若显示为 ro（只读），说明内核已因一致性风险自动降级——此时切勿强行 remount,rw，否则可能触发元数据覆盖

ext3/ext4 误删恢复：extundelete 是首选，但有硬限制

extundelete 快、准、轻量，但它只对“刚删、未覆写、inode 未回收”的文件有效。一旦 rm 后又写了大量日志或临时文件，成功率断崖下跌。

• 必须先卸载分区：umount /dev/sdX1；若无法卸载（如根分区），需从 LiveCD 启动后操作
• 恢复单个文件：extundelete /dev/sdX1 --restore-file "var/log/nginx/access.log"，路径必须是删除前的绝对路径（不含挂载点）
• 恢复全部可找回文件：extundelete /dev/sdX1 --restore-all，结果默认输出到当前目录下的 RECOVERED_FILES/，注意目标盘空间要足够
• ⚠️ 关键限制：extundelete 不支持 ext2（用 debugfs）、不支持 XFS（用 xfs_irecover 或商业工具）、不支持 LVM 逻辑卷直连（需先 lvscan + vgchange -ay 激活）

分区表损坏或格式化后恢复：TestDisk + PhotoRec 组合拳

当 fdisk -l 看不到分区，或误执行了 mkfs.ext4 /dev/sdX，TestDisk 是重建分区表的主力，而 PhotoRec 是兜底的“按文件特征扫描”方案。

• testdisk /dev/sdX → 选 Intel（MBR）或 GPT → Analyze → 若提示 “Quick Search found X partitions”，先试 Write 写回分区表；失败则用 Deeper Search
• 若分区表完全不可逆，或想绕过文件系统直接捞数据，用 photorec /dev/sdX：它不依赖任何元数据，纯靠文件头尾签名识别（如 JPEG 的 FF D8 FF），但恢复出的文件会丢失原名和目录结构，仅保留扩展名与顺序编号
• ⚠️ 注意：photorec 默认跳过已知空闲块，若你刚格式化完就运行，建议加 -d 参数强制全盘扫描（耗时长但更彻底）
• 所有恢复操作的目标路径，必须指向另一块物理磁盘，严禁写回原设备——这是 90% 恢复失败的根源

根分区崩溃无法启动：LiveCD 是唯一安全入口

当你连单用户模式都进不去（比如 GRUB 崩溃、initramfs 找不到 root 设备），本地系统已不可信，一切恢复动作必须脱离原环境。

• 用 CentOS/Rocky Linux 或 Ubuntu Server LiveCD 启动，进入 shell 后先执行：lsblk -f 和 pvs; vgs; lvs（如有 LVM），确认目标卷存在且未被自动激活
• 手动挂载（以 ext4 根分区为例）：

  mkdir /mnt/rescue
  mount /dev/sdX1 /mnt/rescue
  mount --bind /dev /mnt/rescue/dev
  mount --bind /proc /mnt/rescue/proc
  mount --bind /sys /mnt/rescue/sys

  这样才能在 chroot 中安全运行 fsck 或 extundelete
• 若怀疑 superblock 损坏（fsck.ext4 报 “Bad magic number”），可用备份 superblock 恢复：mke2fs -n /dev/sdX1 查找备份位置，再 e2fsck -b 32768 /dev/sdX1

最常被忽略的一点：恢复不是终点，验证才是。别只看文件是否存在——用 file RECOVERED_FILES/nginx.conf 确认 MIME 类型，用 sha256sum 对比备份哈希（如有），对数据库文件还要尝试 mysqlcheck --repair。时间花在验证上，远比重跑一遍恢复划算。