dd命令最致命错误是颠倒if（输入源）和of（输出目标），会导致目标设备被直接覆写且不可逆；务必先用lsblk确认设备名，遵循“从a读、写到b”原则，并添加status=progress、conv=noerror,sync等参数保障安全。
dd 命令写错 if/of 会直接覆写目标设备，没后悔药
用 dd 备份磁盘或做镜像，最致命的错误就是把输入输出搞反——比如本该从硬盘读（if=/dev/sda）却写成 if=/dev/sdb，或者把镜像文件路径误当设备写进 of=。一旦执行，dd 不会确认、不提示、不备份原数据，直接按字节覆盖目标位置。
实操建议：
- 永远先用
lsblk或fdisk -l确认设备名，注意区分/dev/sda（整盘）和/dev/sda1（分区） -
if必须是源（通常是设备），of必须是目标（通常是文件或另一块空盘），写完命令先手动念一遍：“从 A 读，写到 B” - 首次操作前加
status=progress实时看进度，避免干等怀疑卡死 - 如果目标是文件，确保所在文件系统有足够空间——
dd不检查剩余容量，写爆就中断且镜像损坏
备份整盘镜像时别漏掉 conv=noerror,sync
物理磁盘可能有坏道，裸跑 dd if=/dev/sda of=image.img 遇到读错误会直接退出，镜像截断。这不是 bug，是默认行为：dd 把 I/O 错误当严重异常处理。
实操建议：
- 加
conv=noerror,sync：遇到坏扇区跳过，用零填充对齐，保证镜像大小和原盘一致 - 搭配
bs=4M提升吞吐（太小如 512B 效率极低，太大如 64M 在内存吃紧时可能失败） - 不要用
bs=1M试图“更安全”——实际性能差一倍以上，且不解决根本问题 - 若需校验完整性，备份后立刻运行
sha256sum image.img，别等恢复时才发现镜像损坏
恢复镜像到新盘前必须确认目标设备完全清空且尺寸足够
用 dd of=/dev/sdb if=image.img 恢复时，常见失败不是命令错，而是目标盘残留分区表或 LVM 元数据干扰写入；更隐蔽的是目标盘比源盘小——dd 只管写满指定字节数，超出部分静默失败，但前面数据已写歪。
实操建议：
- 恢复前用
sudo wipefs -a /dev/sdb清除所有签名（比dd if=/dev/zero更准更快） - 用
blockdev --getsize64 /dev/sda和blockdev --getsize64 /dev/sdb对比字节数，/dev/sdb必须 ≥/dev/sda - 恢复中加
status=progress和conv=fsync，防止缓存未刷导致看似完成实则没落盘 - 恢复完成后别急着拔盘，先
sudo partprobe /dev/sdb让内核重读分区表，再lsblk看结构是否还原
用 dd 做增量备份？不行，得换工具
dd 是纯字节复制工具，没有文件概念，也不识别变化块。所谓“只备份改动部分”，它做不到。有人试过 dd skip=... count=... 手动切片，结果发现：文件系统元数据（如 ext4 的 journal、bitmap）分布随机，跳着读写的镜像无法挂载或校验失败。
实操建议：
- 真要增量，改用
rsync --one-file-system（文件级）或borgbackup（去重快照） - 若坚持用
dd做定期全量，把镜像文件名带上日期，例如backup_$(date +%F).img，避免覆盖 - 压缩镜像？可以，但必须在
dd完成后单独用gzip或zstd，别用dd | gzip > x.img.gz——中断时整个压缩流报废，无法恢复任何内容
if 和 of 后面跟的到底是什么。
