在线通过dd命令备份分区

一般不推荐在线备份分区，因为在线使用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 参数接的是字节，可用的单位为：

b =512
kB =1000
K =1024
MB =1000*1000
M =1024*1024
GB =100010001000
G =102410241024
T, P, E, Z, Y 的换算关系类似

直接导出硬盘和导分区是有区别的，如果 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.  处理<y>? 是删除 inode 27005985 has zero dtime.  处理<y>? 是删除 inode 101337409 has zero dtime.  处理<y>? 是删除 inode 101337425 has zero dtime.  处理<y>? 是第二步: 检查目录结构目录inode 27000833, 第 块 #0 块, 偏移量 0: 目录损坏修复<y>? 是目录inode 27000833 中缺少 '.'.处理<y>? 是

在文件系统修复过程中有大量的坏块确认，这里强烈建议加上-y参数，不然有超级多的确认需要输入：

$ e2fsck -vfy dev_sda2.img

修复后e2fsck会给出统计信息：

Free inodes count wrong for 簇 #13696 (8192, counted=8191).处理<y>? 是Directories count wrong for 簇 #13696 (0, counted=1).处理<y>? 是Free inodes count wrong (114253815, counted=113440900).处理<y>? 是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 导出。