【简洁篇】
误删linux服务器/下文件目录后恢复经过:
1.用ubuntu桌面版和usb光驱启动系统
2.为athene服务器配置ip,重启网络服务
3.mount硬盘
4.ssh到sion服务器上
5.比较sion和athene服务器的根目录文件,确定丢失文件
6.在sion机器上打包丢失的文件
7.通过rsync命令传输回打包好的文件到athene上
8.解压至相应目录
9.重启服务器。搞定
【啰嗦篇】
2009年4月2日,刚过愚人节,不知道是不是老天给我开了一个迟到的玩笑,那天晚上,在为BugTrace中一些项目手动拷贝workflow的配置文件时,由于使用了不当的参数,再加上又生着病,晕乎乎的,结果失手删除了athene服务器上根目录下的重要文件,导致服务器上所有系统都无法访问。在mic和运维中心同事的紧急抢修下,终于于3日凌晨2时半许恢复。回想起来,惊魂尤未定。写下此篇,一为警戒,二为服务器的数据恢复留下一些经验。
当时的经过是这样的。需要为六十多个项目统一拷贝一些工作流的配置文件,由于是shell白痴,而且在开发机上费了半天边学边写好的shell放到athene服务器上竟然无法运行,无奈之下只能手动拷贝。由于需要删除原先每个项目下的默认工作流文件,用rm命令每次都提示确认,比较繁琐,贪图简便,加上了“-f”参数,(此参数直接导致给我带来了3个小时的噩梦。)在拷贝第五十几个项目的配置文件时,命令行输错,直接开始删除根目录下的文件,当时离我按下enter键仅有1.473秒的时间,但却犹如隔了一个世纪,我赶紧以迅雷不及掩耳盗铃之势按下ctrl+c……当时的时间是公元2009年4月2日22:40左右。
发呆了约莫有3秒钟的时间……回过神后,赶紧访问服务器上的系统,bt、ce、tapd、km,都能够访问到,所以初步断定存放这些系统的/data以及/usr/local(存放apache)目录并未受到删除。然后用ssh登陆,结果发现一直停留在用户名提示界面,输入任何用户名都没有反应,感觉是/etc出了问题。赶紧请6000重启服务器,结果发现不仅用户名无法识别,这下连所有的系统都无法访问了,彻底傻眼,无限崩溃中……
打电话给大牛mic童鞋,根据情况帮我分析可能是/bin或/etc受到损伤。同时在和运维组同事沟通后确立如下两种方案:
方案一:
用已有的ubuntu桌面版和usb光驱启动系统。
进入系统后,将硬盘挂载出来,比较究竟是哪些文件受到损伤。由于sion服务器与athene的配置十分相似,因此可以将这两台服务器的文件目录进行比较。甚至可以通过从sion上复制整个文件夹(如/bin)回来进行覆盖。但前提是athene能够上网,因为公司不允许服务器之间通过任何的外部存储介质进行数据传递。幸好ubuntu桌面版能够通过光驱为服务器配置ip,并且上网。(这点让我觉得很神奇。)
当确认受损的文件后,就可以通过rsync或是fget将文件从sion上打包传回并覆盖。
这样就能搞定。当然,这必须建立在服务器文件受损不严重的基础上,也就是比较乐观的情况。
方案二:
如果无法进入系统,或是无法连接上网络。
将athene硬盘拆卸后挂到其他服务器上。作为从盘启动。
把athene的/data、/usr/local等重要数据文件拷贝到主盘下。由于这两个文件夹下有近百G数据,因此必须确认主盘有足够多的空间。
把athene重装系统,使之能够连上网络,公司将服务器重装后会丢失几乎所有文件。再将刚才那个主盘中的数据拷回至athene。
对于已经/data、/usr/local中已经受损的文件。需通过之前网络备份的机器进行恢复。
此方案是下下策,而且采取这个方案的话,估计我得在公司过一整夜了。
既然方案已经确定,那么就开工。因为我在服务器方面的经验不是很多,所以还是请来了运维组的fetionhe,该gg连夜从家中赶回,其负责之工作态度令人十分的感动和钦佩。
闲话少叙(好像已经说了很多废话

),和justin、fetionhe一起,跑到机房,接上usb光驱,插入chris那里搜罗来的ubuntu光盘。启动,进入系统,当设置ip时,出了一点小的插曲,ubuntu的子网掩码是两位的,因此255.255.255.128对应的是24。重启网络服务后,顺利连上了网络。用mount命令将硬盘挂载出来。执行ssh命令连上sion,比较两者的文件,发现丢失了
/bin和
/boot两个根目录下的文件,幸亏两台服务器的配置十分相似,因此直接tar,打包这两个目录,然后用rsync命令取回后解压,重启,自检,一切都十分顺利。输入root用户名,yeah~~它认出我了!试着访问了一下上面的系统,正常!!只是发现在工作流的配置目录下少了不少项目的配置文件,好在我晚上拷贝之前为了以防万一进行平配置文件备份,多么的英明

。还原,ok!
终于一切大功告成!!还好没有用到第二套方案。
【总结篇】
1.千万不能用太高权限去操作如此重要的服务器,特指root身份。用自己的用户名,加上sudo,虽然繁琐一点,但有二次密码确认,大大降低了发生问题可能性。
2.用rm命令的时候,最好不要带上“-f”参数,实在是太危险了。
3.删除命令是按照字母的顺序开始删的,因此以b字母开头的/boot、/bin才最先遭殃,估计如果我慢零点几秒的话,/data也将惨遭厄运,后怕中……至于工作流配置文件被删,我想是因为当时所在目录是工作流配置文件目录,同时服务器的处理器是双核的,因此另一线就从这里开删,不过这个纯属yy。如果四核的话,估计我就找不到另外两个被删的地方了……汗自己一个
4.避免长时间机械重复操作后导致的疲劳,机械操作一段时间后,记得起来走动一下,喝杯咖啡什么的。尤其是在神智本来就已经有点恍惚的时候。
5.出了问题不要着急,及时发现并终止,评估损失程度,如果自己没有经验,可以请有经验的人士帮忙,并确定补救方案。
6.平时一定要多积累服务器方面的异常情况处理的经验,才能临场从容处理。
7.如此重要的系统应分开部署到不同服务器上,或是虚拟机也行,避免服务器down掉之后,大批系统同时无法运作。
8.同一个重要系统,也最好能够用两台web server,一台出错后,仍有一台可用,保证服务的持续性。
9.对服务器重要文件及时备份,出错后能够及时恢复。
【感谢篇】
要感谢运维组的fetionhe,连夜大老远从家中赶回,并且主导完成了数据的恢复工作。感谢justin一直和我在一起,安慰我,劝我不要着急,给了我很大的鼓励。感谢mic,在半夜还能不断接受我的骚扰,不厌其烦地为我这只菜鸟解释数据恢复和服务器的基础知识。感谢我的mm,深夜为我担忧,直到后半夜。