作者简介
石云华，Exadata中国用户组联合创始人，ORACLE ACE。毕业后一直从事Oracle数据库第三方运维服务工作，拥有十余年电信运营商、保险、税务、电力行业核心系统数据库运维经验。现就职于北京海天起点技术服务股份有限公司，oracle数据库专家组成员，Exadata部门负责人。个人著作有《Exadata实施运维指南》，《Oracle Exadata性能优化》
LVMSnapshot备份
LVM Snapshot备份方式主要用于操作系统损坏非常严重的情景，例如：/boot引导区损坏、或操作系统底层的磁盘全部损坏、RAID5被破坏等等情况。
LVMSnapshot备份方式主要调用了Linux操作系统的LVM功能，操作系统的LVM功能具有很多优点，比如：动态地扩展或收缩文件系统。除此之外，LVM还有一个非常重要的优点，文件系统的备份与还原。即LVMSnapshot特性，LVM Snapshots是瞬间性完成的，保证了备份的一致性。
利用LVM Snapshot备份完操作系统后，务必记住及时删除LVMSnapshot，否则下次操作系统重启时会遇到故障，系统会反复地自动重启。
案例概要：
2017年，给某省移动运营商进行Exadata升级时，现场的同事进行操作系统备份后，重启了操作系统，接着问题来了，发现该计算节点反复地自动重启，系统无法启动。
案例分析：
现场的同事登录该计算节点的ILOM，打开终端控制台观察发现该计算节点在反复地自动重启之前的故障信息如下所示。
Mounting root filesystem. Mount: error mounting /dev/root on sysroot as ext3: Device or resource busy Setting up other filesystems. Setting up new root fs Setuproot: moving dev failed: No such file or directory No fstab.sys, mounting internal defaults Setuproot: error mounting /proc: No such file or directory Setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.32-400.11.1.el5uek #1 Call Trace: [<ffffffff810579a2>] panic+0xa5/0x162 [<ffffffff8109b9b3>] ? atomic_add_unless+0x2e/0x47 [<ffffffff8109be15>] ? __put_css_set+0x29/0x179 [<ffffffff810629ed>] ? exit_ptrace+0x2f/0x118 [<ffffffff8105b076>] do_exit+0x7e/0x699 [<ffffffff8105b731>] sys_exit_group+0x0/0x1b [<ffffffff8105b748>] sys_exit_group+0x17/0x1b [<ffffffff81011db2>] system_call_fastpath+0x16/0x1b Rebooting in 60 seconds... |
根据上述故障中的Call Trace信息搜索MOS网站，发现该故障的主要原因是由于备份时创建的LVM Snapshot没有删除所致。
简单来说，就是内核在引导时根据GRUB传递的root变量的值选择根引导分区，root变量值在/boot/GRUB/GRUB.conf中进行配置。root变量可以设置为保存root文件系统的磁盘设备分区的完整路径，也可以指定文件系统所对应的标签。如果指定了一个标签，内核将检查所有检测到的磁盘设备分区的文件系统标签，并自动选择名称与传递标签匹配的分区。由于文件系统所对应的标签是ext2/ext3属性，所以LVM Snapshot将继承与父LVM相同的标签。
如果在过去的某个时间点对系统进行了手动备份，但是没有卸载和删除LVM Snapshot，系统重新启动时，内核将选择LVM Snapshot作为引导分区，而不是选择/dev/vgexadb/lvdbsys1卷作为引导分区。如果LVM Snapshot处于非活动状态，内核将无法挂载它，并将出现Kernel panic。
案例处理：
弄清楚了整个故障的来龙去脉，故障处理过程则相对比较简单了，只需要将系统启动到诊断模式后，手动删除LVM Snapshot即可，具体命令如下所示。
（1）、使用diag.iso进入诊断模式。 （2）、识别当前系统中存在的LVM Snapshot。 # lvm lvscan # lvm lvdisplay （3）、删除当前系统中存在的LVM Snapshot。 # lvm lvremove /dev/VGExaDb/root_snap Do you really want to remove active logical volume root_snap? [y/n]:Y |
手动删除当前系统中存在的LVM Snapshot后，重启操作系统即可。
在Exadata官方手册中，推荐的root文件系统所对应的LVMSnapshot大小为1GB，/u01文件系统所对应的LVMSnapshot大小为5GB，但是，在真实生产环境中，如果root文件系统或/u01文件系统中的文件变化比较频繁时，则LVMSnapshot的空间容量根本无法容纳这些变化的文件，此时，操作系统的LVM Snapshot备份也会失败，具体案例如下。
案例概要：
一台Exadata X4-2的计算节点进行image升级，在正式升级之前利用LVM snapshot备份操作系统时备份失败，并且报大量IO错误，提示无法找到LVM snapshot的挂载点。检查文件系统状态如下所示。
[root@crmdb02 tar]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VGExaDb-LVDbSys1 30963708 15650472 13740372 54% / /dev/sda1 507748 38319 443215 8% /boot /dev/mapper/VGExaDb-LVDbOra1 103212320 23380548 74588892 24% /u01 tmpfs 264225792 726492 263499300 1% /dev/shm /dev/mapper/VGExaDb-lv_oradump 516061624 273275772 216571452 56% /oradump 10.1.32.196:/dsg2/arch/haitian/ 52071587840 33339427840 18732160000 65% /root/tar df: `/root/mnt/u01': No such file or directory |
发现无法找到/root/mnt/u01挂载点。
怎么在备份的过程中，挂载点突然就自动umount掉了呢？很奇怪，以前也没遇到过啊，还是先看看操作系统的message日志吧,最新的日志信息如下所示。
Nov 26 22:16:02 crmdb02 kernel: Buffer I/O error on device dm-7, logical block 5865474 Nov 26 22:16:02 crmdb02 kernel: lost page write due to I/O error on dm-7 Nov 26 22:16:02 crmdb02 kernel: Buffer I/O error on device dm-7, logical block 5898242 Nov 26 22:16:02 crmdb02 kernel: lost page write due to I/O error on dm-7 Nov 26 22:16:03 crmdb02 kernel: EXT3-fs error (device dm-7): ext3_get_inode_loc: unable to read inode block - inode=3276801, block=6553602 Nov 26 22:16:03 crmdb02 kernel: Buffer I/O error on device dm-7, logical block 0 Nov 26 22:16:03 crmdb02 kernel: lost page write due to I/O error on dm-7 Nov 26 22:16:03 crmdb02 kernel: EXT3-fs (dm-7): I/O error while writing superblock Nov 26 22:16:03 crmdb02 kernel: EXT3-fs (dm-7): error: ext3_journal_start_sb: Detected aborted journal Nov 26 22:16:03 crmdb02 kernel: EXT3-fs (dm-7): error: remounting filesystem read-only |
看到最新的message日志，心里不由地紧张了起来，大量IO错误，还是写superblock时失败，不会这么点背吧，继续看message日志，看看刚出问题时，系统的错误日志，如下所示。
Nov 26 21:50:25 crmdb02 lvm[87105]: Monitoring snapshot VGExaDb-u01_snap Nov 26 21:50:44 crmdb02 kernel: EXT3-fs: barriers not enabled Nov 26 21:50:44 crmdb02 kernel: kjournald starting. Commit interval 5 seconds Nov 26 21:50:44 crmdb02 kernel: EXT3-fs (dm-10): using internal journal Nov 26 21:50:44 crmdb02 kernel: EXT3-fs (dm-10): mounted filesystem with ordered data mode Nov 26 22:10:28 crmdb02 lvm[87105]: Snapshot VGExaDb-root_snap is now 80% full. Nov 26 22:11:58 crmdb02 lvm[87105]: Snapshot VGExaDb-root_snap is now 85% full. Nov 26 22:13:18 crmdb02 lvm[87105]: Snapshot VGExaDb-root_snap is now 90% full. Nov 26 22:14:38 crmdb02 lvm[87105]: Snapshot VGExaDb-root_snap is now 95% full. Nov 26 22:15:53 crmdb02 kernel: device-mapper: snapshots: Invalidating snapshot: Unable to allocate exception. Nov 26 22:15:53 crmdb02 lvm[87105]: Unmounting invalid snapshot VGExaDb-root_snap from /root/mnt. Nov 26 22:15:53 crmdb02 kernel: EXT3-fs error (device dm-7): ext3_get_inode_loc: unable to read inode block - inode=2965505, block=5931010 Nov 26 22:15:53 crmdb02 kernel: Buffer I/O error on device dm-7, logical block 0 Nov 26 22:15:53 crmdb02 kernel: lost page write due to I/O error on dm-7 Nov 26 22:15:53 crmdb02 kernel: EXT3-fs (dm-7): I/O error while writing superblock |
从22：10分开始，系统提示snapshotVGExaDb-root_snap已经占用了80%的空间。22：14分后，snapshot占用近100%，接着就出来大量的IO错误。到了这里，我基本上就知道整个故障的原因了，由于大量的文件变化占用了snapshot，导致划分的1GB的snapshot空间占满，从而自动将文件系统unmount掉。
现在需要解决的是，/(根)文件系统中怎么会出现这么大的文件变化，能在很短的时间内就撑爆1GB的snapshot空间。这些文件变化肯定不是操作系统自己产生的，操作系统自身不会有这么大的文件变化。以前对其他客户的Exadata也备份过很多次，还从没遇到过这种故障。我此时的第一反应是可能存在定时任务，如果定时任务写了日志文件，则很可能会出来这样的情况。
立即检查操作系统用户的crontab情况，发现了如下内容:
[oracle@crmdb02 ~]$ crontab -l 0 * * * * /home/oracle/weihu/scripts/check_db_status.sh >> /home/oracle/weihu/scripts/check_db_status.log 2>&1 & [oracle@crmdb02 ~]$ |
Oracle用户下的确存在定时任务，且该脚本为每分钟执行一次，把输入追加到/home/oracle下的check_db_status.log文件中，而这个文件其实就是/(根)文件系统中。
最终，注释该定时任务，重建该lvm snapshot，重新开始操作系统备份，一切顺利，成功备份完操作系统。
