一般不推荐在线备份分区，因为在线使用dd命令备份分区时，如果硬盘有写入会导致导出的镜像文件的文件系统存在错误。
这次尝试在线备份根分区，主要想看下后续mount时会产生什么问题。
正巧，我在3A平台购买了云服务器，可以测试一下。
dd 命令直接按字节读取硬盘，硬盘上有什么就读到什么，至于上面是文件系统还是分区表它并不关心。所以说它是不挑系统的，所有系统通吃。dd 备份分区命令如下：
$ dd if=/dev/sda2 of=dev_sda2.img bs=1K1827972096+0 records in1827972096+0 records out1871843426304 bytes (1.9 TB, 1.7 TiB) copied, 22207.3 s, 84.3 MB/s
命令说明：
if 是输入文件
of 是输出文件，备份分区时输入输出不能在同一分区
bs 每次读取的字节数
其中 bs 参数会影响读取效率，可以调整 bs 参数来测试导出速度，加一个 count 参数来测试导出相同大小的内容时不同的导出速度。
$ dd if=/dev/sda2 of=/dev/null bs=1K count=10240$ dd if=/dev/sda2 of=/dev/null bs=1M count=10
bs 参数接的是字节，可用的单位为：
直接导出硬盘和导分区是有区别的，如果 dd 的对象是硬盘，比如 /dev/sda 此时导出的内容是带分区表的。如果导出的是分区，则不带分区信息。如果分区已经格式化，则导出的分区是带文件系统的。
当导出完毕，我尝试 mount 导出的文件，此时报错：
$ mkdir -p test$ mount -o loop -t ext4 dev_sda2.img testmount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so.$ dmesg| tail[25909913.190780] EXT4-fs (loop0): error loading journal[25910631.353502] EXT4-fs (loop0): VFS: Can't find ext4 filesystem
当执行 mount 时内核报错，提示找不到文件系统，难道 dd 导出的文件不带文件系统？或者 mount 挂载命令用的不对？
为了排除挂载命令使用没有问题，我打算生成一个镜像文件尝试看能不能挂载成功。步骤是先生成一个空的镜像文件，再使用 mkfs 在镜像文件上生成文件系统，然后挂载这个镜像文件，看 mount 命令是否正确。
$ dd if=/dev/zero of=new.img bs=1M count=3232+0 records in32+0 records out33554432 bytes (34 MB, 32 MiB) copied, 0.0442892 s, 758 MB/s
$ dd mkfs.ext4 new.imgmke2fs 1.42.13 (17-May-2015)Discarding device blocks: 完成Creating filesystem with 32768 1k blocks and 8192 inodesFilesystem UUID: 8a66a04a-9adf-441a-9ed9-b7673e9d6995Superblock backups stored on blocks: 8193, 24577Allocating group tables: 完成正在写入inode表: 完成Creating journal (4096 blocks): 完成Writing superblocks and filesystem accounting information: 完成
$ mount -o loop -t ext4 new.img test$ ls testlost+found
loop 设备是一种特殊的块设备，它用将一个文件映射成虚拟块设备。这样就可以在文件上使用虚拟文件系统。通过 loop 设备，Linux 可以在文件中创建文件系统。
我们检查一下当前测试用的 loop 设备与文件之间的映射关系：
$ losetup -lNAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE/dev/loop0 0 0 0 0 /it/tts/dd/dev_sda2.img/dev/loop1 0 0 1 0 /it/tts/dd/new.img$ umount /it/tts/dd/new.img$ losetup -lNAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE/dev/loop0 0 0 0 0 /it/tts/dd/dev_sda2.img$ umount /it/tts/dd/dev_sda2.imgumount: /it/tts/dd/dev_sda2.img: not mounted
此时说明 loop 设备的绑定也没有问题，无法 mount 只说明文件系统出了问题。我们是在 /dev/sda2 在线状态导出的，也就是说没有 umount 这个分区，此时文件系统还处于读写状态。执行 dd 读取分区时有可能文件系统上会出现不一致的情况。我们尝试修复文件系统，看导出的镜像文件能否能正常打开。
$ e2fsck -vf dev_sda2.imge2fsck 1.42.13 (17-May-2015)ext2fs_open2: Bad magic number in super-blocke2fsck: 超级块无效, trying backup blocks...超级块没有needs_recovery标志，但是日志中没有数据。Recovery flag not set in backup 超级块, so running 日志 anyway.dev_sda2.img: 正在修复日志第一步: 检查inode,块,和大小删除 inode 8657418 has zero dtime. 处理? 是删除 inode 27005985 has zero dtime. 处理? 是删除 inode 101337409 has zero dtime. 处理? 是删除 inode 101337425 has zero dtime. 处理? 是第二步: 检查目录结构目录inode 27000833, 第 块 #0 块, 偏移量 0: 目录损坏修复? 是目录inode 27000833 中缺少 '.'.处理? 是
在文件系统修复过程中有大量的坏块确认，这里强烈建议加上-y参数，不然有超级多的确认需要输入：
$ e2fsck -vfy dev_sda2.img
修复后e2fsck会给出统计信息：
Free inodes count wrong for 簇 #13696 (8192, counted=8191).处理? 是Directories count wrong for 簇 #13696 (0, counted=1).处理? 是Free inodes count wrong (114253815, counted=113440900).处理? 是dev_sda2.img: ***** 文件系统已修改 *****
812924 inodes used (0.71%, out of 114253824) 1537 non-contiguous files (0.2%) 453 non-contiguous directories (0.1%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 754175/818 26930922 blocks used (5.89%, out of 456993024) 0 bad blocks 5 large files
632546 regular files 105582 directories 57 character device files 25 block device files 118 fifos 114521 links 74580 symbolic links (57716 fast symbolic links) 9 sockets------------ 927410 files
在文件系统扫描的过程中，有些坏块导致文件受损，这些受损的内容会存放到文件系统的 lost+found 目录。
文件系统修复后，我们尝试使用 mount 挂载镜像文件：
$ mkdir -p test$ mount -o loop dev_sda2.img test$ cd test$ df -h .Filesystem Size Used Avail Use% Mounted on/dev/loop1 1.7T 76G 1.6T 5% /it/tts/dd/test
最终成功挂载，也可以查看到镜像文件的内容。如果要使用 dd 备份文件系统或分区，一定要在分区 umount 状态下执行 dd。虽然可以在线执行，但导出的镜像文件的文件系统存在错误。虽然可以通过 e2fsck 进行修复，但有可能出现文件受损的情况。为保证文件系统的一致性，应该在 umount 下执行 dd 导出。