redhat labs之dump备份与restore恢复

一、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相关文件系统的备份工具。其支持将备份文件备到磁带、存储和本地。其用法如下：

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

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

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

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

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

二、dump备份级别

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

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

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

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

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

三、restore恢复

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

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

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