一次linux服务器管理的惨痛教训

2019-07-14 03:17发布

系统用的是fedroa8,机房给装系统的时候,分区按默认方式,用lvm管理。后来一次机房给拔了一下电,估计文件系统哪儿出问题了,磁盘全部变成只读。然后我想检查一下磁盘,运行了一下fsck,结果检查失败,而文件系统又被卸载掉了,所有命令都用不了。只好让机房给重启一下,然后系统就起不来了。怀疑机房重启系统的时候发现系统没反应,多起了几下,导致系统检查硬盘的过程被中断。为了保存数据,我只好重新加了块硬盘,把系统装在新硬盘上,挂上旧硬盘,我慢慢恢复数据。先是遇到lvm的分区挂载问题,这东西不能像别的分区一样直接挂在。网上查了一下:先用vgscan,找到虚拟卷,然后用 vgchange -ay 激活虚拟卷,/dev下就有了虚拟卷设备。  默认是/dev/VolGroup00/LogVol00 /dev/VolGroup00/LogVol01这样的。用 mount  /dev/VolGroup00/LogVol00 /root/vg0 挂载,结果报错:mount: you must specify the filesystem type用fdisk查看 了一下,发现虚拟卷识别出来了,但就是分区表被破坏了,系统识别不出分区格式。只好再用fsck修复。不停提示,开始还看,后来烦了,加了个    fsck -y。好,一路顺利,检查完了。mount上虚拟卷,进入目录,傻眼了,分区下只剩下一个lost+found文件夹,别的啥都没了。进到lost+found下面,ls了一下,等了半天才显示出来结果。原来所有文件都被移到这个文件下了,并且都重命名为以#开头,一串数字结尾的文件,好几万文件。欲哭无泪啊。无奈间,试着grep了一下,发现还好,有的文件夹名字变了但结构还在。赶忙写了个shell脚本恢复数据。幸运的是,主要数据基本上都恢复了。总结了一下教训:1。fsck不能乱用。先要把文件系统umount掉,然后检查。最好启动到单用户模式下fsck。 2。不必要的时候不要用lvm。真不知道fedora为什么默认用lvm,为了实验技术?这个鬼东西把硬盘弄成一块,要坏全坏,还影响磁盘io性能。网上看到还有把boot文件夹也放到lvm下的,这样系统起不来的时候,你想手动加载一下内核地址,你都不知道内核地址应该怎么表示。3。分区和备份太重要了。数据库的datadir要手动指定到放数据的分区下,这样重装系统的时候,数据不会丢失。etc目录下的配置文件要备份,不然系统重装后,重新配置一边也够受的。 平时自己本地用linux,服务器管理经验不多,让老鸟看了笑话。吃一堑长一智,我这也算长了一智。