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。时间花在验证上，远比重跑一遍恢复划算。
