4月2日惊魂夜——记athene服务器丢失数据的紧急恢复

04月 4th, 2009 by robert
【简洁篇】

      误删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,深夜为我担忧,直到后半夜。

部门2009新年晚会——请给他人起码的尊重

01月 18th, 2009 by robert

经过了两个多星期的精心准备,我们的节目终于要在部门的新年晚会上亮相了。从挑选主题到素材的搜集,从辛苦的练习到道具的准备,在这两个节目上,我们投入了大量的精力和时间。因此,我们最期盼的,是晚会上观众开心的笑声和此起彼伏的掌声。

可是,当我们上台演出时,我彻底傻眼了:大部分的座位都空着,剩下的,只是一些裁判、部门领导和我们自己的组员,以至于我们演出时的许多包袱都没有抖响,很多我们之前认为很劲爆的笑料都没有达到预期的效果。后来我才知道,原来其他组的成员都去场外准备自己的节目去了,或是去化妆,或是去换服装,或是为本来准备的不是很周全的节目作最后的修饰和彩排。于是,才有了这一篇博文。

部门的新年晚会,我们每一个人都同时担任着两种角色:演员和观众。不管是出于想给大家更精彩的节目也好,是出于想获奖,拿奖金也好,在别人演出的时候,去准备自己的节目,都是不对的。因为这样做完全是忘记了自己的另一个身份:一名忠实的观众。试想,如果所有的人都在别人表演的时候不在场,那么这台晚会与平时的组内练习又有什么区别呢?对于他人的节目,报以热烈的掌声,或是笑声,在演出的时候不随便离场,是作为观众起码的要求,也是对他人一种起码的尊重。

或许有人会说,是因为我们的节目都在第一个,所以才会在表演完了自己的节目后,有时间留在现场,如果我们的节目在后面,自然也会出去准备。此话差矣,我对我们小组的所有成员有足够的信心,我们会对所有的演员表示出足够的尊重。事实上,去年我们做到了如此,今年如此,以后也将如此。就拿我个人来说,我认真观看了所有的节目,即使晚饭喝多了,出去上厕所也是挑在两个节目的空档时间。为的就是不错过任何一个别人花了精力准备的细节。

这是一场比赛吗?绝对不是,这只是一场晚会而已,所以不能把结果看得太重,需要我们保持一种游戏的心态:享受晚会的筹备和正式环节。而我们,的确做到了投入到整个过程,从准备到演出,我们的团队表现出了非凡的天赋和团结力,在这个团队里,我体会到了大家的热情,大家的朝气,大家的激情。其实,在宣布最终的结果之前,我已经作好了拿第二或是第三的准备了(关于节目的详细评论,请看随后的《乱评节目篇》),因为我承认我们的节目没有其他组准备的足够“充分”,也没有他们的精彩。我享受到了整个团队给我带来的良好氛围,这就足够了。让我失望的是,似乎有些组太注重结果了,所有才有了让roger和mic上台所谓的“谢罪”,简直是胡闹,所幸我们的两位裁判表现出了足够的大将风范,才使这一风波稍得平息。本以为步入职场多年的人会把这场所谓的“比赛”看得平淡,没想到却还不如我们这些毕业不久的后生。

晚会结束了,总体说来还是很成功的,给了大家很多美好的回忆,但也有不少是值得我们去思考的。对于这个小小的疙瘩我一直放不下,所以才先写了这篇,更多美好的总结会稍后奉上。

用jquery.form.js插件时,回调函数showResponse不起作用

01月 9th, 2009 by robert

用jquery.form.js来做表单的ajax提交,从网上拷了代码下来以后,就调用处的代码没有做太多修改,结果发现success参数指定的showResponse回调方法没起作用。搜索了一把以后,发现是没有对dataType这个参数进行设置,现将options参数的详细解释作说明,以示警醒:

target:指明页面中由服务器响应进行更新的元素。元素的值可能被指定为一个jQuery选择器字符串,一个jQuery对象,或者一个DOM元素。
默认值:null。

url:指定提交表单数据的URL。
默认值:表单的action属性值

type:指定提交表单数据的方法(method):“GET”或“POST”。
默认值:表单的method属性值(如果没有找到默认为“GET”)。

success:表单成功提交后调用的回调函数。如果提供“success”回调函数,当从服务器返回响应后它被调用。然后由dataType选项值决定传回responseText还是responseXML的值。
默认值:null

dataType(就是这里了):期望返回的数据类型。null、“xml”、“script”或者“json”其中之一。dataType提供一种方法,它规定了怎样处理服务器的响应。这个被直接地反映到jQuery.httpData方法中去。下面的值被支持:

xml:如果dataType == ‘xml’,将把服务器响应作为XML来对待。同时,如果“success”回调方法被指定, 将传回responseXML值。

json:如果dataType == ‘json’, 服务器响应将被求值,并传递到“success”回调方法,如果它被指定的话。

script:如果dataType == ’script’, 服务器响应将求值成纯文本。