dd备份磁盘需先确认设备名与大小：用lsblk -f查挂载关系，fdisk -l看容量，dmesg查usb设备名；必须加bs=4m、conv=noerror,fsync、status=progress；不可备份挂载中的根分区；备份后须用file、fdisk、mount -o loop,ro及sha256sum校验。
dd 备份磁盘不是“一键傻瓜操作”，它直接读写裸设备，错一个参数或路径就可能覆盖关键分区甚至整个系统盘——必须先确认设备名、大小、用途，再加 conv=noerror,fsync 和 status=progress 才算基本可用。
怎么确认要备份的磁盘设备名和大小
误把 /dev/sda 当成目标写入，结果覆盖了系统盘，这种事故太常见。不能靠猜或看上次命令，得现场查：
- 用
lsblk -f看挂载关系和文件系统，区分/dev/sda（整盘）和/dev/sda1（分区） - 用
sudo fdisk -l /dev/sda确认总扇区数和实际容量，避免目标盘比源盘小却没发现 - 如果目标是 USB 盘，插拔前后运行
dmesg | tail -20，看内核日志里识别出的设备名（比如sdb而不是sdb1） - 别信
df -h显示的“可用空间”——它只反映文件系统层，dd操作的是底层块设备，必须看物理容量
备份整盘时必须加的关键参数
不加参数硬跑 dd if=/dev/sda of=/dev/sdb，表面成功，但可能丢数据、卡死、或恢复后无法启动：
-
bs=4M：默认 512 字节太慢；4M 是多数 SSD/HDD 的友好值，太大（如 64M）反而触发 I/O 队列溢出 -
conv=noerror,fsync：noerror让遇到坏扇区时继续复制（否则中断），fsync强制刷写缓存，防止断电丢最后几 MB -
status=progress：实时显示已复制字节数和速率，没这句你只能干等，不知道是卡住还是正常 - 不要加
oflag=direct做整盘备份——它绕过页缓存，对大块顺序写反而降低吞吐，只在测裸盘读速时有用
为什么不能直接用 dd 备份正在挂载的根分区
即使加了 sync，dd if=/dev/sda2 of=backup.img 仍大概率产生不一致镜像，因为：
- 文件系统有缓存（page cache）、日志（ext4 journal）、元数据延迟更新，
dd只管块，不管语义 - 备份过程中如果有进程写文件、删日志、改 inode，镜像里就会出现“一半新一半旧”的混合状态
- 恢复后可能
fsck报错，甚至无法挂载——这不是dd的 bug，是它设计如此：它复制的是那一刻的磁盘快照，不是文件系统快照 - 真要备份运行中的系统，要么进 live 环境（如 Ubuntu Live USB），要么用
rsync+lvm snapshot或btrfs send/receive
备份后如何快速验证镜像可用性
备份完成不等于能用。镜像损坏或截断往往要到恢复时才发现，那时已晚：
- 立刻用
file backup.img看是否识别为“data”或具体文件系统类型（如 “Linux rev 1.0 ext4 filesystem data”） - 用
fdisk -l backup.img检查分区表是否完整可读，输出应含类似 “Disk backup.img: 20 GiB, 21474836480 bytes” 和分区行 - 临时挂载只读测试：
sudo mount -o loop,ro offset=1048576 backup.img /mnt（offset 是第一个分区起始偏移，用fdisk -l查），能列出文件就说明基础结构完好 - 别跳过校验：备份前后分别运行
sudo dd if=/dev/sda bs=1M count=100 | sha256sum和dd if=backup.img bs=1M count=100 | sha256sum，前 100MB 哈希一致才可信
dd 的危险性不在命令本身，而在它不提醒你风险——它安静地执行每一个字节的复制，包括你误写的设备路径、未清空的目标盘、正在被写的源分区。真正安全的备份，永远始于设备确认和最小化假设，而不是参数调优。
