一、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命令还原,还原完成后,直接重启即可。
《redhat labs之dump备份与restore恢复》有1条评论