写这篇博客的目的主要是警醒自己在Linux运维操作时刻不能掉以轻心，无论涉及什么样的操作都应该慎重，尤其对运行核心业务的系统，操作前确认系统的运行环境。
事由介绍：
开发的同事找我协助部署sybase数据库的自动备份，数据库架构为RHCS高可用集群，数据库部署在共享磁盘sda中，同时反馈说集群也是有问题，无法自动切换，以下记录操作失误和恢复的全过程。
1、当天下午我登陆sybase数据库服务器，首先查看了系统版本：
#cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.6
2、查看磁盘
# fdisk -l ---------- Disk /dev/sda: 600 GB, 299999952896 bytes 255 heads, 63 sectors/track, 36472 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sda doesn‘t contain a valid partition table Disk /dev/sdb: 600 GB, 299999952896 bytes 255 heads, 63 sectors/track, 36472 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sdb doesn‘t contain a valid partition table
3、查看文件系统sda挂载在/opt,sybase数据库安装目录.
4、问题出现就在我和同事协商备份文件存放位置时，我向同事确认是否系统挂载了两块外置磁盘，也就
是共享LUN，他说确实挂载了两块外置磁盘，不经确认我相信了他，怎么说看起来就是前辈，那我建议就说sdb也没有用，就用来存放备份数据吧，他肯定说sdb确实没有用，可以用来存放备份数据，接下来我执行了下面命令：
#mkfs.ext3 /dev/sdb #mkdir /backup #chown sybase:sybase /backup #mount /dev/sdb /backup
悲剧也就从这里开始
我开始部署脚本自动备份，但是查看备份日志（/home/sybase/dump.log）自动备份脚本一直不成功，过程中我手动执行了sybase数据库master的备份到/home/sybase，备份是成功的，又在测试环境（自己电脑之前部署过sybase RHCS高可用集群）测试自动备份成功,这不科学啊，接下来：
#cd /backup #ll drwxr-xr-x 18 sybase sybase 4096 Jan 9 15:24 ASE-15_0 drwxr-xr-x 5 sybase sybase 4096 Jan 9 12:24 ASEP drwxr-xr-x 59 sybase sybase 4096 Jan 9 12:15 charsets drwxr-xr-x 3 sybase sybase 4096 Jan 9 12:15 collate drwxr-xr-x 2 sybase sybase 4096 Jan 9 12:18 config drwxr-xr-x 2 sybase sybase 4096 Jan 9 12:51 data drwxr-xr-x 4 sybase sybase 4096 Jan 9 12:20 DataAccess drwxr-xr-x 4 sybase sybase 4096 Jan 9 12:20 DataAccess64 drwxr-xr-x 5 sybase sybase 4096 Jan 9 12:21 DBISQL -rw-r--r-- 1 sybase sybase 155 Jan 9 14:57 interfaces -rw-r--r-- 1 sybase sybase 70 Jan 9 12:38 interfa.old drwxr-xr-x 9 sybase sybase 4096 Jan 9 12:17 jConnect-7_0 drwxr-xr-x 8 sybase sybase 4096 Jan 9 12:14 jre32 drwxr-xr-x 3 sybase sybase 4096 Jan 9 12:17 jutils-3_0 drwxr-xr-x 4 sybase sybase 4096 Jan 9 12:15 locales drwxr-xr-x 2 sybase sybase 4096 Jan 9 12:42 log drwxr-xr-x 16 sybase sybase 4096 Jan 9 12:28 OCS-15_0 drwxr-xr-x 10 sybase sybase 4096 Jan 9 12:20 shared -rwxr-xr-x 1 sybase sybase 2037 Jan 9 12:25 SYBASE.csh -rw-r--r-- 1 sybase sybase 1091 Jan 9 12:25 SYBASE.env drwxr-xr-x 2 sybase sybase 4096 Jan 9 12:15 Sybase_Install_Registry -rwxr-xr-x 1 sybase sybase 1620 Jan 9 12:25 SYBASE.sh drwxr-xr-x 3 sybase sybase 4096 Jan 9 12:25 SYBDIAG drwxr-xr-x 4 sybase sybase 4096 Jan 9 12:15 sybuninstall drwxr-xr-x 6 sybase sybase 4096 Jan 9 12:26 SYSAM-2_0 drwxr-xr-x 13 sybase sybase 4096 Jan 9 12:23 UAF-2_5 drwxr-xr-x 8 sybase sybase 4096 Jan 9 12:25 WS-15_0
一看到这头皮就炸了，这不是sybase安装文件吗!特别是个别目录不停自动闪动
#multipath -ll 没有输出
#service multipathd status 没有启动
联系开发同事到后台存储阵列一看，就一个LUN被map到这两台数据库服务器
可以确认/sda和/sdb就是同一块磁盘了，原因大家也清楚，就不多说
但是数据库当前还能正常运行，文件都还在，上网查看相关资料是否能修复格式化后的文件系统，也就是重建inode节点，重新找回数据，结果前途一片黑暗啊，这里说下开发同事，当我向他表明情况后，他很乐观，没事，数据丢不了，做了raid1,亲娘差点我哭了。
我问了一位高手，他说修复的概率很低，也没有具体方法，建议请专业数据恢复公司来做！
先不管，目前不是数据库还能正常读写吗！果断的手动将业务数据库备份出来。
同时也想把sybas数据库安装文件也cp一份，但是执行操作：
#du -sm * 报错，提示找不到文件 #ll 整个安装文件全部消失
彻底事大了
在修复文件系统机会渺茫的情况下，我决定重建sybase数据库，再导入业务数据库恢复，这时客户催命电话响起，我让开发同事先实情告诉客户，同时把刚备份出来的数据传送给开发同事导入开发测试库查看数据是否完整能用（不确定MKFS后导出来的数据是否有效），不然就得使用以前的备份数据，这会导致数据丢失，我这边立马重新部署数据库。
幸好开发同事反馈备份数据有效，接下来我就安装业务数据库，导入备份数据，执行恢复操作，恢复操作成功，心里压力终于放下，事后整个人后怕不已。
数据库恢复过程中也碰到了字符集的问题，以及安装数据库设备文件时提示设备文件需要原库设备文件大小，都一一解决了。
现在留下几个问题，也请大家能给出答案：
1、文件系统格式化之后，Linux系统基于什么机制使得文件不会立马消除？
2、du这个命令为什么会清除数据，机制又是什么？
3、mkfs后有什么方式能修复文件系统？