一、dump工具

在RHEL Backup and Restore Assistant上提供的备份恢复工具有dump、tar、cpio、rsync和dd。本篇就先从dump说起。在其相关页面上有这么一句‘Command Dump is the official tool provided by Red Hat to address backing up the ext2, ext3, and ext4 file systems.’ —-官方提提供的，针对ext相关文件系统的备份工具。其支持将备份文件备到磁带、存储和本地。其用法如下：

1# dump [-0123456789ackMnqSu [-A file ] ]  files-to-dump

注：注意该工具是针对挂载点的，而对于挂载下的子目录是不行的。 备份的时候一般是指定分区名，也可以使用挂载点名称。使用示例如下

 1# 一般使用/dev/sda1这样的用户去备，使用/boot这样也可以成功
 2[root@361way ~]# dump -u0 /boot -f /opt/boot.dump
 3  DUMP: Date of this level 0 dump: Mon Jul  2 17:11:43 2018
 4  DUMP: Dumping /dev/sda1 (/boot) to /opt/boot.dump
 5  DUMP: Label: none
 6  DUMP: Writing 10 Kilobyte records
 7  DUMP: mapping (Pass I) [regular files]
 8  DUMP: mapping (Pass II) [directories]
 9  DUMP: estimated 225470 blocks.
10  DUMP: Volume 1 started with block 1 at: Mon Jul  2 17:11:46 2018
11  DUMP: dumping (Pass III) [directories]
12  DUMP: dumping (Pass IV) [regular files]
13  DUMP: Closing /opt/boot.dump
14  DUMP: Volume 1 completed at: Mon Jul  2 17:11:49 2018
15  DUMP: Volume 1 226080 blocks (220.78MB)
16  DUMP: Volume 1 took 0:00:03
17  DUMP: Volume 1 transfer rate: 75360 kB/s
18  DUMP: 226080 blocks (220.78MB) on 1 volume(s)
19  DUMP: finished in 3 seconds, throughput 75360 kBytes/sec
20  DUMP: Date of this level 0 dump: Mon Jul  2 17:11:43 2018
21  DUMP: Date this dump completed:  Mon Jul  2 17:11:49 2018
22  DUMP: Average transfer rate: 75360 kB/s
23  DUMP: DUMP IS DONE
24# 挂载点下的目录不成功
25[root@361way ~]# dump -u0 /etc -f /opt/etc.dump
26  DUMP: You can't update the dumpdates file when dumping a subdirectory
27  DUMP: The ENTIRE dump is aborted.
28# boot能成功是因为其是一个单独的挂载点
29[root@361way ~]# df -h|grep boot
30/dev/sda1              4.8G  230M  4.4G   5% /boot

上面使用的参数u，是在/etc/dumpdates里记录备份（默认记录最近的三条），其里面记录的结果类似如下：

1[root@361way ~]# cat /etc/dumpdates
2/dev/sda1 0 Mon Jul  3 17:11:43 2017 +0800

二、dump备份级别

从上面第一部分的示例也可以看出，其支持0-9种备份策略，其中0是全量备份，1-9是增量备份，用哪个并没有区别，哪么差异备份呢？dump的差异备份非常有意思，可以用一个游戏形容 —- 开心消消乐。看下图：

dump
dump

我个面做了个一周备份的表格，可以看到当1遇到后面的1时，周四的备份就会把从周2到周四所有的备份进行合并，即差异备份（和周一全量的差异）。因为周2的备份被合并了，所以周五的备份级别2还是增量备份，直到周日，备份级别2又出现了一次，所以又是差异常备份。

可以通过如下步骤做一个测试：

 1[root@361way opt]# df -h|grep sda1
 2#全备
 3[root@361way opt]# dump -0u /dev/sda1 -f /opt/sda1_0.dump
 4[root@361way opt]# du sda1_0.dump -sh
 5#增量
 6[root@361way opt]# dd if=/dev/zero of=/boot/dump1 bs=1M count=20
 7[root@361way opt]# dump -1u /dev/sda1 -f /opt/sda1_1.dump
 8[root@361way opt]# du sda* -sh
 9#增量
10[root@361way opt]# dd if=/dev/zero of=/boot/dump2 bs=1M count=30
11[root@361way opt]# dump -2u /dev/sda1 -f /opt/sda1_2.dump
12[root@361way opt]# du sda* -sh
13#差异
14[root@361way opt]# dd if=/dev/zero of=/boot/dump3 bs=1M count=10
15[root@361way opt]# dump -1u /dev/sda1 -f /opt/sda1_3.dump
16[root@361way opt]# du sda* -sh

通过查看每次的备份文件大小就可以看出端倪。当然如果你觉得还是有疑问也没关系，还可以通过restore还原验证我们的推论。

三、restore恢复

还是接上一步的实验，我们把/boot下的所有内容干掉，通过备份sda1_0.dump和/opt/sda1_3.dump 两个文件就能完成所有数据的还原，如下：

 1[root@361way boot]# history |tail -9|grep -v tail
 2 1009  dump -0u /dev/sda1 -f /opt/sda1_0.dump
 3 1010  dd if=/dev/zero of=/boot/dump1 bs=1M count=20
 4 1011  dump -1u /dev/sda1 -f /opt/sda1_1.dump
 5 1012  dd if=/dev/zero of=/boot/dump2 bs=1M count=30
 6 1013  dump -2u /dev/sda1 -f /opt/sda1_2.dump
 7 1014  dd if=/dev/zero of=/boot/dump3 bs=1M count=10
 8 1015  dump -1u /dev/sda1 -f /opt/sda1_3.dump
 9# 备份还原测试
10[root@361way boot]# rm -rf /boot/*
11[root@361way boot]# restore -rf /opt/sda1_0.dump
12[root@361way boot]# restore -rf /opt/sda1_3.dump

当然，这里是系统都好的情况下。如果系统出问题了怎么办？道理一样，重启进入修复模式。把有问题的分区直接格式化（我有备份我怕啥），使用之前备份好的文件通过restore命令还原，还原完成后，直接重启即可。