dumpe2fs /dev/sdb1 2>/dev/null | grep -i "backup superblock"可列出所有备份超级块位置，典型值有32768、98304、163840等；若失败，可用mkfs.ext4 -n /dev/sdb1推算或hexdump手动搜索ef 53签名。
用 dumpe2fs 列出所有备份超级块位置
主超级块损坏时，dumpe2fs 是最直接可靠的工具。它会扫描整个文件系统，从块组描述符中提取所有已写入的备份超级块地址。
必须确保目标设备已卸载（如 /dev/sdb1），否则输出可能不完整或报错。
- 执行：
dumpe2fs /dev/sdb1 2>/dev/null | grep -i "backup superblock" - 常见输出类似：
Backup superblock at 32768, Group descriptors at 32769-32896 - 典型位置有：
32768、98304、163840、229376、294912……间隔通常为 65536（即 64KiB × 块大小） - 若无输出，说明
dumpe2fs无法读取主结构——此时可退而求其次，用mkfs.ext4 -n模拟格式化来推算
用 mkfs.ext4 -n 推算默认备份位置
当 dumpe2fs 完全失败（比如设备只读损坏、I/O 错误频繁），mkfs.ext4 -n 是安全的备选方案：它不写入任何数据，仅模拟创建过程并打印规划信息。
该命令依赖当前内核和 e2fsprogs 版本的默认策略，对大多数 ext4 分区有效，但不保证 100% 匹配原始布局（尤其手动指定过 -g 或 -b 的情况）。
- 执行：
mkfs.ext4 -n /dev/sdb1 - 查找输出中类似：
Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 - 注意：该命令会尝试读取设备以获取现有 UUID/label 等，若设备严重损坏，可能卡住或报错；此时应改用
hexdump手动搜索
用 hexdump 在日志区或固定偏移处搜索 53ef
ext4 超级块签名是固定的 2 字节：53ef（小端序，实际磁盘上为 ef 53）。0 号块组超级块固定位于逻辑块 0 的 1024 字节偏移处（即字节偏移 1024），但备份块位置不固定——不过 journal 区或块组开头常残留未擦除的签名。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
这不是首选方法，仅适用于 dumpe2fs 和 mkfs.ext4 -n 都失效，且你愿意花时间逐块排查的场景。
- 先确认块大小：
tune2fs -l /dev/sdb1 2>/dev/null | grep "Block size"（若失败，按常见值 4096 尝试） - 尝试搜索常见备份块起始位置（单位为字节）：
dd if=/dev/sdb1 bs=4096 skip=32768 count=1 2>/dev/null | hexdump -C | head -5 - 观察输出前几行是否含
ef 53—— 若有，该块极可能是可用备份超级块 - 更暴力但有效的方式：
grep -a -b -o "\xef\x53" /dev/sdb1 | head -20（需 root，且可能误报；\xef\x53是签名的小端二进制形式）
为什么不能只依赖一个备份块号？
备份超级块不是“永远可用”的镜像。它们在文件系统运行中不会实时同步更新——只有某些关键操作（如 resize、feature 启用）才会刷新全部备份。所以一个备份块可能比主块还旧，甚至 checksum 已失效。
修复时务必按顺序尝试多个备份块号，且每次 e2fsck -b 后检查返回码和提示。遇到 Superblock has a bad checksum 不代表该块彻底报废，有时加 -f 强制校验能绕过校验失败（但风险上升）。
真正麻烦的是：所有备份块都损坏，且日志区也残缺。这时候 dumpe2fs 查不到位置，mkfs.ext4 -n 给的只是理论值，hexdump 搜索又像大海捞针——得靠 debugfs 读 stats、人工算块组描述符偏移，再结合 dd+hexdump 交叉验证。这种层级的操作，稍错一位偏移就全盘皆输。
