redhat labs之dump备份与restore恢复

2017年7月15日 发表评论 阅读评论

一、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的差异备份非常有意思,可以用一个游戏形容 ---- 开心消消乐。看下图:

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命令还原,还原完成后,直接重启即可。




本站的发展离不开您的资助,金额随意,欢迎来赏!

You can donate through PayPal.
My paypal id: itybku@139.com
Paypal page: https://www.paypal.me/361way

分类: Linux/unix/mac 标签: