夜战联通机房－－－邮件服务器起死回生

 原贴:http://coolerfeng.blog.51cto.com/133059/77863

夜战联通机房－－－邮件服务器起死回生

---

2008-05-20 00:59:00

　标签： 恢复 服务器 邮件 　　　[ 推送到技术圈]

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 http://coolerfeng.blog.51cto.com/133059/77863

一台邮件服务器出现了故障，具体导致故障的原因不明，初步怀疑是硬盘或者scsi卡不正常。并且不能远程 ssh登录到机器上来查看原因，          下班了就赶往机房，中间省略若干无关的事件。来到机器跟前一看，比上一次更严重。。开机启动的时候就提示若干lib库找不到，控制台下无法输入密码进入机器。现象为输入完用户名后，根本就不提示输入passwd，由于已经22:00了，时间紧迫，就不试图修复了，直接重装系统吧。         接上外置光驱，将系统安装到一个新的硬盘上。注意分区的时候不要搞错了，以免把原来的系统给格式化掉了。安装好系统后挂载上原来的硬盘，在mnt下建立对应原有分区的目录，把原来的硬盘的各个分区分别挂载到对应的目录里面，这里具体的对应关系就凭感觉了，有经验的话，挂载上，一列目录就能看出来那个分区大概是什么目录挂载的了。很幸运的是/dev/sda2对应的就是/,/dev/sda3大概对应的是/usr/ /dev/sda5 对应/var 交换分区swap和/boot可以忽略把/usr/local目录下的东西打包复制到新系统的相同地方tar czvf local.tgz /mnt/sda2/local，同时还需要复制的东西有/etc/rc.local /etc/postfix/* /etc/ld.so.conf 复制的时候用cp -Rp参数来复制目录和对应的权限 接下来需要创建用户和组。找到原来系统盘下面的/etc/passwd,/etc/group,根据里面的内容来添加所需要的用户和组，注意需要指定用户的uid和gid。useradd -u;groupadd -g 用户创建成功后，开始启动原来rc.local中定义的服务。 启动apache和mysql的时候很顺利 接下来启动postfix遇到了一些麻烦。提示找不到libmysqlcilent.so 从原系统中的/etc/ld.so.conf覆盖到/etc/后，手动运行一下ldconfig就可以了 再启动postfix，一堆error，大意就是缺少/usr/sbin/post*之类的文件，挨个复制过去，或者cp -p /mnt/sda3/sbin/post* /usr/sbin 还有/var/spool/postfix，这里感慨一下postfix还是比较乱，如果安装到一个目录就好了。 当然肯定还有手册之类的，不过这里我就没有复制他们了，毕竟postfix已经正常启动了 查看一下端口，apache，mysql，postfix都已经各就各位了 查看/var/log/maillog也没有异常 接下来启其他的一些服务。除了amvisd需要perl模块外，其他服务都比较顺利。 由于没有笔记本电脑，无法测试能否正常发信和收信。只能先闪了，后续的测试工作则需要结合/var/log/maillog的具体提示来完成了，到这里已经可以远程ssh操作了，时间也很晚了，于是收工走人，临走的时候保安还为难我，说我有一张临时出入证没有归还，不把身份证给我，经过电话联系后和保安交涉，最后确认是保安交接工作的疏忽，靠，无语了。赶紧回家睡觉吧。   到这里，一台严重损坏的linux服务器抢救复活了，如果有时间的话，可以分析一下原来系统为什么损坏，并可以试图修复一下   需要说明的是，本案例能够正常恢复程序，有几个必要因素 1，硬盘没有出现物理损坏，如果磁盘出现坏道，而要拷贝的数据偏偏在坏扇区上，那是神仙也没辙的事情，遇到这种情况，你只能自认倒霉了。 2，良好的安装习惯。合理的分区结构。把大部分应用用源码安装在/usr/local或者/home这样的地方是一个很好的习惯，使得程序移植起来很容易，在相同的操作系统环境，相似的硬件环境下，几乎不会有什么问题。这其实和windows下的所谓“绿色软件”的原理是一样的。如果是用rpm安装的应用程序，你会发现移植是很头疼的事情，依赖关系，满天飞的配置文件和二进制启动文件，本文中的postfix就有这样的问题。另外分区结构也是很好的习惯，把/usr/local,/var,/etc这些重要的目录用单独的分区，这样即使硬盘出现故障，也能把损失降低到最小程度，如果图省事，用系统默认的LVM，所有目录在同一个分区，遇到硬盘故障的情况下，恢复数据是一件比较挑战技术和耐心的事情，而实际环境下，留给运维人员去慢慢解决问题的时间往往是很短的，工作重在结果，而不是过程，因此，如何更快的让服务器能提前恢复正常，比linux爱好者在那挖空心思琢磨一个古怪的问题如何解决更重要一些。   3.相同的操作系统和库环境。linux有很多发行版，如果试图把debian上的程序移植到redhat，不进行一番调整是很难成功的。因此，原来的系统和现在的系统最好一模一样，最好连小版本都一样，比如不要用centos5和centos5.1来匹配。这样的目的是保证系统自带的lib库等尽量一致。如果实在不能运行，只能设法去拷贝相同的库文件，或者重新编译相关程序了，而这两个方案都会浪费很多的时间。如果可以的话，程序最好能够静态编译，做到尽量不依赖系统的库，这样移植性更好。   4备份配置文件，如果实在是因为某些原因导致某些程序无法正常运行，我们可能需要重新编译安装，如果事先有相关的配置文件备份，就可以快速的让程序恢复正常，而不是又重新调试程序，逐个修改配置文件中的相关部分。邮件服务器的配置比较复杂，对配置文件的备份是很重要的工作。   5建立详细的文档，如果有了安装时候记录的详细文档，在恢复服务器的时候会更加方便，很多时候，我们习惯于把相关的知识记在大脑，这样一旦不是当事人来亲自操作，其他人很难恢复的和原来一样周全，难免漏掉一些死角，如果间隔了较长时间，或者人事变动的话，相应的维护工作会更加困难，完整详细的文档，对自己，对他人都会有帮助。养成这样的好习惯会从中受益的