最常导致数据丢失的操作是将整块磁盘（如/dev/sdb）误当作分区（如/dev/sdb1）格式化；必须用lsblk确认带数字的设备名、FSTYPE和MOUNTPOINT为空，且已卸载，再执行mkfs.ext4，并验证卷标与预留空间。
确认目标设备是分区，不是整块磁盘
最常导致数据丢失的操作，就是把 /dev/sdb（整盘）当成 /dev/sdb1（分区）去格式化。整盘格式化会覆盖分区表，让所有已有分区“消失”，哪怕里面存着重要备份也救不回来。
必须先运行 lsblk，看清楚 NAME 列里带数字的才是分区（如 sdb1、nvme0n1p2），FSTYPE 为空、MOUNTPOINT 为空的才可能是待格式化目标。NVMe 盘的分区名末尾带 p，比如 /dev/nvme0n1p1，别漏掉这个 p。
- 如果
lsblk显示sdb下没有子项（即没sdb1），说明还没分区，得先用fdisk /dev/sdb或parted /dev/sdb创建分区 - 如果看到
sdb1但 MOUNTPOINT 不为空，说明已挂载，必须先卸载
必须先卸载再格式化，否则命令会失败或静默拒绝
mkfs.ext4 遇到已挂载的设备，多数情况直接报错 Device is busy，但某些内核版本或挂载方式下可能跳过检查、强行写入——结果是文件系统损坏，后续 mount 失败或数据错乱。
执行 sudo umount /dev/sdb1 后，再跑一次 lsblk 确认 MOUNTPOINT 列确实为空。不要依赖“我记得刚才 umount 过”这种记忆，多敲一次 lsblk 花不了两秒，却能避开 90% 的误操作事故。
mkfs.ext4 和 mkfs -t ext4 本质一样，但参数习惯不同
两者调用的是同一套底层逻辑，mkfs -t ext4 实际就是 exec 到 mkfs.ext4。选哪个只影响脚本可读性和团队规范，不影响功能。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
日常手动操作推荐用 mkfs.ext4，因为更直白；写自动化脚本时用 mkfs -t 更统一，方便以后切换 xfs 或其他类型。
- 加卷标便于识别：
sudo mkfs.ext4 -L backup2026 /dev/sdb1 - 调低 root 预留空间（默认 5%，对大容量数据盘浪费）：
sudo mkfs.ext4 -m 1 /dev/sdb1 - 指定块大小（仅当明确需要，如匹配应用 IO 模式）：
sudo mkfs.ext4 -b 4096 /dev/sdb1
格式化后别急着挂载，先验证卷标和文件系统状态
格式化成功只代表 superblock 写入完成，不代表一切就绪。尤其在旧设备或有残留元数据的盘上，UUID 冲突、journal 损坏都可能导致后续 mount 失败或只读挂载。
建议立刻验证两件事：
- 查卷标是否生效：
sudo e2label /dev/sdb1，输出应与-L参数一致 - 看预留空间是否按预期：
sudo dumpe2fs -h /dev/sdb1 | grep "Reserved block count" - 如果要长期用作数据盘，顺手跑一次
sudo tune2fs -c 0 -i 0 /dev/sdb1关掉强制 fsck（避免重启时卡住）
真正容易被忽略的是：格式化完不验证，直接写进 /etc/fstab 并 reboot —— 一旦标签或 UUID 错了，系统可能卡在 emergency mode 进不去。
