Exadata LVM snapshot备份失败

一台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日志，心里不由地紧张了起来，I/O错误，还是写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分开始，系统提示snapshot VGExaDb-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，重新开始操作系统备份，一切顺利，成功备份完操作系统。