让WordPress使用Redis缓存来进行加速

Redis是一个高级的key-value存储系统,类似memcached,所有内容都存在内存中,因此每秒钟可以超过10万次GET操作。

我下面提出的解决方案是在Redis中缓存所有输出的HTML 内容而无需再让WordPress重复执行页面脚本。这里使用Redis代替Varnish设置简单,而且可能更快。

安装 Redis

如果你使用的是 Debian 或者衍生的操作系统可使用如下命令安装 Redis:

apt-get install redis-server

或者阅读 安装指南

使用 Predis 作为 Redis 的 PHP 客户端

你需要一个客户端开发包以便 PHP 可以连接到 Redis 服务上。

这里我们推荐 Predis. 上传 predis.php 到 WordPress 的根目录。

前端缓存的PHP脚本

步骤1:在WordPress 的根目录创建新文件 index-with-redis.php ,内容如下:

<?php

// Change these two variables:

$seconds_of_caching = 60*60*24*7; // 7 days.

$ip_of_this_website = ‘204.62.14.112’;

/*

– This file is written by Jim Westergren, copyright all rights reserved.
– See more here: www.jimwestergren.com/wordpress-with-redis-as-a-frontend-cache/
– The code is free for everyone to use how they want but please mention my name and link to my article when writing about this.
– Change $ip_of_this_website to the IP of your website above.
– Add ?refresh=yes to the end of a URL to refresh it’s cache
– You can also enter the redis client via the command prompt with the command “redis-cli” and then remove all cache with the command “flushdb”.

*/

// Very necessary if you use Cloudfare:

if (isset($_SERVER[‘HTTP_CF_CONNECTING_IP’])) {
$_SERVER[‘REMOTE_ADDR’] = $_SERVER[‘HTTP_CF_CONNECTING_IP’];
}

// This is from WordPress:

define(‘WP_USE_THEMES’, true);

// Start the timer:

function getmicrotime($t) {
list($usec, $sec) = explode(” “,$t);
return ((float)$usec + (float)$sec);
}

$start = microtime();

// Initiate redis and the PHP client for redis:

include(“predis.php”);
$redis = new Predis\Client(”);

// few variables:

$current_page_url = “http://”.$_SERVER[‘HTTP_HOST’].$_SERVER[‘REQUEST_URI’];

$current_page_url = str_replace(‘?refresh=yes’, ”, $current_page_url);

$redis_key = md5($current_page_url);

// This first case is either manual refresh cache by adding ?refresh=yes after the URL or somebody posting a comment

if (isset($_GET[‘refresh’]) || substr($_SERVER[‘REQUEST_URI’], -12) == ‘?refresh=yes’ || ($_SERVER[‘HTTP_REFERER’] == $current_page_url && $_SERVER[‘REQUEST_URI’] != ‘/’ && $_SERVER[‘REMOTE_ADDR’] != $ip_of_this_website)) {
require(‘./wp-blog-header.php’);
$redis->del($redis_key);

// Second case: cache exist in redis, let’s display it

} else if ($redis->exists($redis_key)) {

$html_of_current_page = $redis->get($redis_key);

echo $html_of_current_page;

echo “<!– This is cache –>”;

// third: a normal visitor without cache. And do not cache a preview page from the wp-admin:

} else if ($_SERVER[‘REMOTE_ADDR’] != $ip_of_this_website && strstr($current_page_url, ‘preview=true’) == false) {
require(‘./wp-blog-header.php’);
$html_of_current_page = file_get_contents($current_page_url);
$redis->setex($redis_key, $seconds_of_caching, $html_of_current_page);
echo “<!– Cache has been set –>”;

// last case: the normal WordPress. Should only be called with file_get_contents:

} else {
require(‘./wp-blog-header.php’);
}

// Let’s display some page generation time (note: CloudFlare may strip out comments):

$end = microtime();
$t2 = (getmicrotime($end) – getmicrotime($start));
if ($_SERVER[‘REMOTE_ADDR’] != $ip_of_this_website) {
echo “<!– Cache system by Jim Westergren. Page generated in “.round($t2,5).” seconds. –>”;
}
?>

或者直接下载 index-with-redis.php

步骤2:将上述代码中的 IP 地址替换成你网站的 IP 地址

步骤3:在.htaccess 中将所有出现 index.php 的地方改为 index-with-redis.php ,如果你使用的是 Nginx 则修改 nginx.conf 中的 index.php 为 index-with-redis.php(并重载 Nginx : killall -s HUP nginx)。

性能测试

1.没有Redis 的情况下,平均首页执行1.614 秒,文章页0.174 秒(无任何缓存插件)

2.使用Redis 的情况下,平均页面执行时间0.00256秒

我已经在我的博客中使用了如上的方法进行加速很长时间了,一切运行良好。

其他建议

我的环境是Nginx + PHP-FPM + APC + Cloudflare + Redis. 安装在一个 nano VPS 中,无缓存插件。

请确认使用了gzip压缩,可加快访问速度。

访问 wp-admin

要访问 wp-admin 必须使用 /wp-admin/index.php 代替原来的 /wp-admin/.

原文:jimwestergren 编译:oschina

哪7句话是安慰人时禁忌讲的?

我们社会如此惧怕死亡和悲伤真的不是你的错,因为从来没人教育我们,如何与悲痛中的人相处。以下呢,是七句你不该说的话,以及表达它们的更好方式。

1.别说“他去了一个更好的地方”或“你应该高兴,他不再受病痛折磨了。”
她想要他在的地方就是她的身边,无论他是否收到病痛折磨或者照顾他是多么困难。
更好的表达方式:“你一定非常想念他。”

2. 别说“你很快就能另得佳偶”或“你随时都能再生一个”或“至少你还有其他子女。”
但他这时满心悲痛、全心想寻回的那人却不在他身边,永远也无法以他人取代。尊重逝者吧。
更好地表达方式:“我知道她对你而言有多特别,也知道你爱她有多深。”

3. 别说“是时候让自己振作起来了。”
每个人悲痛的过程都是和别人不同的。也许这还不是她可以“振作起来”的时候。就算她目前还无法恢复正常,好好地照顾自己或家人,最好的解决办法也是让朋友或亲密的人暂时帮助照顾家里人一阵子,而不是使她感到羞愧,觉得自己“没能更好地处理这件事。”
更好地表达方式:“今天你一定过得不太好。我六点左右给你们带点晚餐过来如何?”

4. 别说“我敢肯定一切都会很快好起来的。”
糟糕!眼睁睁地看着朋友或家人受到悲痛折磨真是太难受了….我们往往想让他们感觉好点,这样我们自己才会感觉好点!记住,他也许正在想,自己永远不会开心起来了,因此你对他未来感受的主管臆断可能会让他非常烦闷。
更好地表达方式:“只要你需要我,我会一直在你身边。”

5. 别说“上帝总是有最好的安排。这一定是他的意愿。”
这可能会使悲痛者对上帝或其他神祗产生愤怒。另外,在提到上帝或任何其他神祗之前,了解对方的信仰系统也很重要。不要假定他和你有一样的信仰。
更好地表达方式:“我感到很难过。”

6. 别说“别在孩子面前哭。”
对孩子们来说,更让他们感到不安的是隐瞒真相,而不是开诚布公。因此,让孩子们感受到正常的悲痛并无不可。
更好地表达方式:“孩子们现在还好吗?”

7. 别:什么都不说。
事实上,这对悲痛中的人来说是最糟糕的情况了:人们对他的痛苦采取忽视态度。如果你不确定该说什么,或者不肯定对方是否愿意谈起此事,也可以就这样说:
更好地表达方式:“我不知道该说什么,但我想让你知道,我会一直陪着你。”和/或“你现在想谈谈她去世的经过吗?”
记住,和悲痛中的人在一起的时候,最重要的事情是:陪在她身边。有时候你甚至不需要讲话。她只需了解,你愿意在她伤心时陪她坐一会儿。

鱼-陈绮贞

陈绮贞-《鱼》

我坐在椅子上 看日出复活
我坐在夕阳里 看城市的衰弱
我摘下一片叶子 让它代替我
观察离开后的变化
曾经 狂奔 舞蹈 贪婪的说话
随着冷淡试戴浮华
带不走的 丢不掉的 让大雨侵蚀吧
让他推向我在边界奋不顾身挣扎
如果有一个怀抱勇敢不计代价
别让我飞 将我温柔环绕
我坐在椅子上 看日出复活
我坐在夕阳里 看城市的衰弱
我摘下一片叶子 让它代替我
观察离开后的变化
曾经 狂奔 舞蹈 贪婪的说话
随着冷淡试戴浮华
带不走的留不下的我全都交付他
让他捧着我在手掌 自由自在挥洒
如果有一个世界浑浊的不像话
原谅我飞 曾经眷恋太阳
带不走的丢不掉的让大雨侵蚀吧
让它推向我在边界奋不顾身挣扎
如果有一个世界浑浊的不像话
我会疯狂的爱上
带不走的留不下的我全都交付他
让他捧着我在手掌自由自在挥洒
如果有一个怀抱勇敢不计代价
别让我飞 将我环绕
原谅我飞 曾经眷恋太阳
原谅我飞 曾经眷恋太阳

20130202:一首好久没有听的歌,再次听起来真让人回味,好像是大学早期听到的,传给过几个朋友听过,后来有个女同学说是她传给我的,但我觉得是我传给她的。啊,我也不知道了,呵呵,缘分吧。想想那时候的很多朋友都没有联系了,不管是因为地理因素,还是感情因素,还是各种当时自己不成熟的表现,总之结果是基本不联系了。怅惋吗?也许这就是年轻的代价,这就是成长吧。能改变的,只有自己的心态心境,坦然面对,积极的生活。忽然发现歌词里有个词语“叶子”,还在思念吗?不可避免的。也许真的印证了歌词“我摘下一片叶子,让它代替我”。看看他们走过的路,终于知道自己的位置,时间空间,好像把自己的人生都看到了一样。不过这一切都要改变了,新的生活就要开始,未知的未来,我相信会有惊喜的。

经济科学参考书

一、入门教材:人大版《经济科学译丛系列》

   1、曼昆《经济学原理》上下册,88元。梁小民教授翻译。曼昆为哈佛高才生,天才横溢,属新古典凯恩斯主义学派,研究范围偏重宏观经济分析。

  该书为大学一年级学生而写,主要特点是行文简单、说理浅显、语言有趣。界面相当友好,引用大量的案例和报刊文摘,与生活极其贴近,诸如美联储为何存在,如何运作,Greenspan 如何降息以应付经济低迷等措施背后的经济学道理。该书几乎没有用到数学,而且自创归纳出“经济学10大原理”,为初学者解说,极其便利完全没有接触过经济学的人阅读。学此书,可了解经济学的基本思维,常用的基本原理,用于看待生活中的经济现象。可知经济学之功用及有趣,远超一般想象之外。推荐入门首选阅读。目前国内已经有某些教授依据此书编著《西方经济学》教材,在书中出现“经济学10大原理”一词,一眼便可看出是抄袭而来。

  2、 萨缪尔森《经济学》(Economics)

  萨缪尔森,新古典综合学派的代表人物,1970年成为第一个荣获诺贝尔经济学奖的美国人。研究范围横跨经济学、统计学和数学多个领域,对政治经济学、部门经济学和技术经济学有独到的见解。目前经济学各种教科书,所使用的分析框架及分析方法,多采用由他1947年的《微观经济分析》发展糅合凯恩斯主义和传统微观经济学而成的“新古典综合学派”理论框架。他一直热衷于把数学工具运用于静态均衡和动态过程的分析,以物理学和数学论证推理方式研究经济。目前经济学理论数学化大行其道,此翁实始作俑者。

  《经济学》由美国麦格劳——希尔图公司1948年初版。现已出第16版,通行全世界。国内50年代由高鸿业教授根据英文第10版翻译,商务印书馆于1981年出版。市面之16版,是和诺德豪斯合写,由萧深教授翻译。

  全书结构宏伟,篇幅巨大。可谓博大精深。渗透老萨数十年经济学见解。字里行间,三言两语,每有深意。其中诸如“热情的心,冷静的头脑”、“相关未必因果”等言语,可谓经济学之《老子》。读完该书,可了解经济学所探讨问题在经济学体系中之位置及分析框架,对经济学有一个完备之认识框架。知识庞杂,有一体系框架,则适宜以后更进一步学习。学之愈深,愈知此框架之重要。尽管该框架在宏观经济学的微观基础方面仍有断层,但不失为一个好框架。此书国内有机工版发行之英文版。建议直接阅读英文版。

  3、斯蒂格利茨《经济学》及系列辅助教材。斯蒂格利茨在信息经济学成就甚高,此书可作为前二者的补充,前二者所涉及经济学内容主要是以价格理论及边际分析为基础,不包括不对称信息经济学、不确定性分析部分。斯蒂格利茨之《经济学》可填充前二者之空白。

  尽管三位作者政策倾向不同,但教材体现凯恩斯主义的特征稍多一点,总体上讲,教材相当客观和公允。很适宜做入门教材。

  4、《经济学、原理、问题与政策》及《经济学原理与问题》、《经济学案例》、《经济学小品》、《经济学悖论》、《社会问题经济学》等。此类书之特点是先提问题,再论原理,主要是针对社会习见问题,逐步解释原理,水平、内容大多较好,唯缺乏体系与框架,适宜略懂经济学者补充学习。

  5、国内老师自行编写之《西方经济学》教材:目前国内各大学自己编写的直接冠以《西方经济学》或《经济学原理》均属入门教材。如高鸿业、历以宁、宋承先、梁小民、朱锡庆、尹伯成、司春林等等。然皆远逊外国教材。其中宋承先之《西方经济学》教材,竟用黑体加插一段马克思论地租之说法,以说明所传授学问之错误,实为极可笑者。

  说明:

   1、越基础性之教材越需深入浅出,将复杂抽象的道理联系到生活实际上,才讲的透彻,又能调起初学者之兴趣。国外教材,形成一竞争市场,多极高明之著作,教材之撰写也充分考虑学生学习之便利,如曼昆之教材,以完全不带数学式而著称,又或更新换版本极快,以及时吸收新知识,如斯蒂格利姿《经济学》之增加不对称信息部分。低手所写教材自然被市场淘汰。故市面之基础教材,多为大高手所写就。

   2、国内教材,建国以来,除商务系列丛书初期之100年前古典学派部分,政府同意翻译以作为马克思批判之反面教材得以出版外,80年代以前,近50年间国外经济学研究学问之成就,国人皆不得见。80年代末期,邹至庄先生力倡西方经济学,邓大人首肯之后,国内始渐有《西方经济学》之类教材出现。此类教材,多为新出道之老师,为进阶升职,凑出版物之数而编抄西人著作而成,机制所限,不敢添加“反动”之知识,又无竞争机制,购买者多为其听课学生。故质量甚差,若非特殊目的如考研指定者,慎勿购买。

   3、按经济学有入门低、中级、高级之分。高级乃指其运用之数学工具及阐述观点之纷争更多而言,并非此学问高人一等。一如高等数学未必高初等数学一等之意。越是高级,则越多分歧,也越追求数理逻辑之严谨,反不如低级来的实用。初级的入门教材一般是针对初学者,所以大多举案例和现象,加以文字解释,偶尔插加二维图案,高级教材注重数理逻辑,而二维图案及文字已难以表达、解决所说明之问题,故多用数学证明或代数方程,夹杂现代数学工具。中级教材则介乎其中,界定甚为模糊。教材难度不同,跨度也相差很大。

    

   二、中级微观教材

  中级教材一般以微观、宏观两科为主,兼修其他应用科目。传统经济学,本无宏观、微观之分,自凯恩斯针对名义变量进行宏观经济分析之后,始有宏观一科。故历来次序,先修微观,再修宏观,后及其他。

  微观经济学为各科之基础。其分析,乃基于马歇尔的一般均衡分析及边际效用学派之边际分析,而后由萨缪尔森发展数学方法及框架而成,涵盖范围甚广,大致包括:

  基础部分:传统厂商理论(技术、利润、成本)、传统消费者理论(效用、偏好、选择、需求)、局部均衡理论(完全竞争市场之稳定性)、一般均衡理论(福利经济学二大定理、交换方框图)

  分支部分:寡头市场理论(寡头、定价、市场细分)、博奕论(纯策略均衡、混合博奕、广延型结构、厂商博奕、颤抖的手)、公共物品理论(公共物品、税收制度设计、投票、外部效应)、不确定性经济学(风险、博采、保险、投资)、信息经济学(不对称信息、逆向选择、信号)、激励理论(委托-代理理论、契约理论)、法和经济学(制度经济学、企业性质分析、法律)、拍卖理论(拍卖机制设计)、匹配理论等。

  学习者可根据上述内容,与教材所列提纲比较,则可知教材侧重点之所在。

  6、《管理经济学》,有版本数种,特点各不相同。此类教材多为MBA系列教材。其目的针对生产过程决策而设,故与经济学之中级微观教材相较而言,减少少量分支部分理论,增加回归分析及计量统计部分。目前数种版本中,以人大版《工商管理经典译从》难度最低。机工版哈耶所写之《管理经济学—战略与决策》与标准中级教材难度大致相当,内容也接近。唯其中也已采用函数表达式。机工版莫瑞斯(有英文版及中文版,中文为陈章武所译)《管理经济学》难度最高,其侧重内容与中级教材大不相同,除回归分析已采用大量数据,要求建立模型,内容接近计量预测外,内容涉及对偶理论、不同代替效应之图解,附录采用微分法,难度较高。此类书籍,侧重经济学中与管理交叉管理。

  7、平狄克《微观经济学》人大版,此书乃标准中级微观经济学教材。在美国多个大学供MBA采用,国内英文版有清华版,中文版有人大版。此书内容适中,主题广泛,均是各部分理论之要点,不旁及其他分歧内容,其中定价部分较为详细。图形清晰,语言流畅。所采用数学工具甚浅,有函数但不涉及微分,只用差值。曲线只用标准严格凹性曲线,不及拟凹部分、线性仿射内容,成本函数也均为线性。建议此书应通读,可作进阶之用。

  8、曼斯非尔特《微观经济学》人大版,内容、难度、书价与平狄克相仿,唯编排次序不同。体系稍显庞杂,不如平狄克之明晰,然也为一国外通行教材。若修习平狄克有不明之处,则可先参照此教材或先修学其他国内出版之书籍。如北大系列教材之周惠中〈微观经济学〉,北大版朱善利之《微观经济学》等。此书不属必读。

  9、《国外经济学教材库》系列之《应用微观经济学》,32开,经济科学出版社。此书有大量案例及微观经济原理之运用,所用数学甚少,读此书,可补充平狄克教材之案例。加深对经济学之了解。

  10《微观经济学: 现代观点》(Intermediate microeconomics)[美] 范里安(Varian, Hal R.)著,费方域翻译。据美国W.W.诺顿图书公司 1990年版译出,三联版。此书是极规范之经济学专业的中级微观教材。美国MIT,哈佛、伯克利经济学本科指定教材。32开,800多页。易懂而深刻。本书为第二版,内容除论述了市场、消费者偏好、需求、技术、利润、生产等问题,还增加了两章, 分别论述了要素供给和信息经济等。内容上相当关注技术细节问题,比平狄克要更深一些。范里安微观经济学与数学造诣极深。然此书乃其为学生所写之中级教材,刻意避免数学之应用,大部分数学推导放于附录,微分运用相当少,适宜学完平狄克后重点阅读。可作平狄克中各部分理论内容之拓展。

  

 三、中级宏观教材

若无意进一步学习高级微观经济学,则可同时学习宏观经济学。微观的特点是精深,宏观则是驳杂。因为宏观流派很多,观点各不相同。

  11、《宏观经济学》曼昆,人大版。中文翻译。此书秉承曼昆《经济学原理》之优点,以简单,浅显为特点。虽只有很少量的数学,但对原理及内容均提炼得甚为简洁。前半部分写得相当清晰。可读完萨缪尔森《经济学》并略懂一点微观后直接学习。适宜一个循环学习,即以书入手,修完《全球视角》后,再回头重修此书,有提纲挈领之用。缺点是作者似乎限于门户之见,对真实周期学派、奥地利学派等其他学派提得很少。建议阅读。

  12、《宏观经济学》多恩布什。人大版中文翻译,东北财大有影印英文版。此书是标准的中级宏观教材,属正统教材。体系清楚,描述准确,通行于美国各大学多年。采用凯恩斯IS-LM体系为框架,对各个流派评价及描述相当公平。推荐必读。

  13、《宏观经济学》人大版,中文翻译。罗伯特霍尔,整本书显得有点凌乱,适宜读过其他中级宏观再做印证之用,内容比上述两本教材略深。不属必读范围。

  14、《宏观经济学》巴罗。清华,影印英文版。巴罗宏观经济学造诣很深,主要研究领域在经济增长理论。但写的书却销路很差。学这本书可作为对上述教材所属凯恩斯学派的一个补充。不属必读范围。

  15、《全球视角的宏观经济学》三联版 杰佛里萨克斯,32开,1000页。萨克斯成功处理了南美高通货膨胀的问题,但书一样写的相当好,整本书注意细节而有条理。很适宜读完多恩布什《宏观经济学》后进一步阅读。以拓展知识。上述5种教材所用符号各不相同,对学习者实在甚为不便。

  16、《国际经济学》 保罗克鲁格曼,今日之宏观经济学,已很难讨论封闭的宏观经济,此书可谓进一步拓展的宏观经济学,包括国际贸易和国际金融两个部分,渗透克鲁格曼的经济思想,所采用框架为AS-AD框架,可作IS-LM框架的补充。推荐阅读。

  17、《现代宏观经济学发展与反思》及《现代宏观经济学指南—各思想流派分析》及《与经济学大师对话》此系列三册,前两册为商务版。此书乃对各不同流派经济学大师的采访和评论,对各个流派的异同可以有清楚的了解,而且是直面经济学大师,可以看到各个大师之间彼此的观点不同,甚至成见立场,互相抨击之处,实在有趣。推荐阅读。

  

  四、其他教材:,

  18、人大版《经济科学译丛》系列之其他大多数教材:《经济思想史》、《财政学》、《公共部门经济学》、《人事经济学》、《金融学》(博迪)、《投资学》、《货币银行学》(米十金)等等实务应用之科目。适当补充阅读《公共选择理论》、奥地利学派、哈耶克、剑桥之争、非瓦尔拉斯均衡分析、等等内容。

  19、三联丛书黄皮书系列,其中显要者如《公共经济学》(Lectures on public economics)(阿特金森(Atkinson, Anthony B.) [美] 斯蒂格里茨(Stiglitz, Joseph E.)著)、《政治与市场: 世界的政治—经济制度》、《财产权利与制度变迁: 产权学派与新制度学派译文集》、《经济史中的结构与变迁》、《货币、银行与经济》(Money, Banking, and the Economy)〔美国〕托马斯.梅耶(Thomas Mayer)、《法和经济学》等等。可对经济学之应用领域获得一个深刻视角。三联丛书,推荐全部阅读。

  20、张五常《卖橘者言》、《佃农理论》、《经济解释》。张老先生近年是国内焦点所在,也写了几本〈随笔〉,发表不少演讲,大体而言,〈随笔〉不堪一读,其中论书法、摄影部分,不关主旨,且水平甚低,多属偏颇之见,今不论之。唯上述专著中之《佃农理论》,见解独到,尤有过人之处。建议修完中级微观后仔细阅读。《经济解释》则为论文集,然其中也有不少过激之言论及偏见,不可以教材视之。其中“合约理论”部分,可以一读。论“共产主义”部分,则未必有理。

  21、杨小凯《经济学原理》《新兴超边际古典经济学》,杨先生气魄甚大,欲以一己之力重写传统经济学体系,与汪丁丁先生有异曲同工之妙。可谓经济学之异端,读之可开阔视野。推荐阅读。

  22、《波斯纳文集》苏力翻译。老先生以法学专才,写《法之经济学分析》,实一极高明之人士,于此不可不提。推荐阅读。

  23、商务丛书《汉译世界名著》系列:此丛书系列,自二十世纪初商务王云五先生主持,与是事者不计其数,除文革中断十余年外,每年陆续出版,涵盖哲学(红皮)、历史(黄皮)、政治(绿皮)、经济(蓝皮)、语言学、人类学(未成),所翻译者,非经典不收,皆大师之精华,所主持翻译之人,多博学鸿儒或一代大师。单经济一门,翻译之著作,至今已近百种。百年间,传播知识无数,可谓功德无量。读完蓝皮经济类之全部,则可通晓经济学之来龙去脉。

    

  至此,无意于经济学一门谋生者,已然足够。然上述书籍,常人阅读,少者耗时约需1、2年以上。多者3、5年。且其中论著,多高明之作,或有一读再读之需,而读完,也或有“屠龙之技”之感也未之定,一笑!

    

  五、数学工具:即所谓数理经济学一科

  若数学水平较高,有意进一步玩弄经济学之数学智力游戏,则可参读以下数学工具:中国大学本科考研究生之数学三(高数、线性代数、概率论与数理统计)为必修之基础课,其他之数学工具则包括拓扑学初步(凸集、凹集、微分方程稳定性)、线性规划(代数理论、几何理论、对偶理论)、非线性规划(不等式约束规划)、变分法(欧拉方程、泛函函数、收敛问题、可变端点、横截条件、勒让得必要条件、相图分析)、最优控制理论(最大值原理、汉密尔顿函数)、连续时间优化规划、离散时间优化规划(不动点性质、值函数)、时间序列分析、非线性混沌系统、随机变量等等。

  24、《经济学中的数学》(入门水平)

  25、蒋中一《数理经济学基础》(基础水平)

  26、《动态优化基础》(进阶水平)

  27、高山成(takayama)《经济学中的优化方法》(推荐阅读)

  28、龚六堂《经济学中的优化方法》(推荐阅读)

  29、《经济学中的动态递归方法》(推荐阅读)

  30、《数理经济学手册》人大版(重点阅读)

  

六、中高级微观经济学

下文书籍,未必尽是高明著作,然国内此类教材甚少,下述书籍,聊胜于无。

  31、平新乔的《微观经济学18讲》,北大出版。内容属于中高级微观经济学,涉及微观领域较多,引入大量的数学运算,除文字内容外,强调逻辑推理。惟书中有不少印刷错误,且理论内容跳跃太快,不利学习理解,数学运用庞杂,不够明快清晰。在国内中高级教材中属中上之作,接近国外大学本科高年级水平。最大的优点是书后付有大量需要运算的习题,均需花时间读书和思考才能解决,很适宜学习训练。对从中级到高级过渡有帮助。不属必读范围。(CCER考博要用)

  32、张定胜《高级微观经济学》。武大出版。此书属于中高级内容,因涉及主题较少,故比平新乔之《18讲》显得清晰。适宜找不到其他中高级教材,而高级教材又甚困难,可以此书做过渡。

  33、 Nicholson 《 Microeconomic Theory》国内中文翻译出版。此书微积分运用、数学运算简洁明晰,全书难度、体系一致,排版清楚、内容重点突出,主题有深度,实为一极佳之中高级教材。书后之参考书目适宜进一步学习参考,为中级教材之中,最适宜和高级教材接轨者,唯书价稍贵,习题难度不深,习题量稍显不足。此书似乎出版发行量不多,除北大、复旦等处书店有少量可见外,其他大学及城市似甚少见。推荐阅读。

  34、蒋殿春《高级微观经济学》,经济管理出版社。此书主题基础部分已达高级水平,难度甚大。至博奕论以后部分,则难度甚浅。或与日本经济学之教授方法有关。对传统的价格理论的数学描述相当清楚。数学证明部分清楚。推荐阅读。

  35、张维迎《高级微观经济学》,此书张教授5、6年前在香港做访问学者时已准备出版,张五常之论著中,多处注释引自此教材,多种丛书翘首以待,均将此书名印于丛书之中,以待出版。然数年一去悠悠,至今未见面世。张教授微观造诣甚深,想来此书必也不错。估列于此处,他日或可望出版,若有见张教授者,也可代问此书出版之日。呵呵。(说实话,按照国际的标准,张维迎还很嫩很嫩,其理论方面的贡献几乎没有,数学也不行,我对此书不报任何希望)

  36、范里安《高级微观经济学》经济管理出版社。这是范里安在《微观经济学—现代观点》的基础上的标准高级教材。每一章均相当简短但精要。阅读时需要对中级教材有比较深入的学习。但翻译质量不佳。建议直接读英文版。接近研究生一年级水平。推荐阅读。(中译本确有不少错误)

  37、武康平《高级微观经济学》,清华版。进一步学习数理经济学之用。不属于必读范围。

  38、《微观经济学》《microeconomics theory》andrew.mas-colell Green等,社科院,中文版,北大翻译。110元。经典中的经典目前所见,顶级教材,研究生一年级水平。推荐阅读。(国外博士生一年级广泛使用此书)

    

  七、高级宏观经济学

  39、 《高级宏观经济学》 戴维 罗默。商务版。推荐阅读(国内名校考博开始使用此书)

  40、 布兰查德《高级宏观经济学》

  41、 萨金特《动态宏观经济理论》

  42、 龚六堂《高级宏观经济学》、《经济增长理论》。推荐阅读

    

  八、其他教材

  43、《计量经济学》、《数理经济学》、《数量经济学》、《经济增长理论》、《金融经济学》《产业组织理论》、(泰勒尔)。属于研究生初级教材。

  44、中国社会科学文献出版社《哈佛剑桥经济学著作译丛》:《经济理论的进展》(上下)、《公共选择理论》、《治理机制》、《不确定性与信息分析》、《经济学中的制度》推荐全部阅读。

  45、社会科学出版社《国外经济学名著丛书》系列:《企业经济学》、《农业发展的国际分析》(速水右次郎)、《同意的计算》(布坎南)、《货币数量论研究》(佛里德曼)推荐全部阅读。

  46、经济科学出版社《国外经济学教材库》系列:此系列水平介于本科与研究生之间,若学完上述其他教材,此系列可不必阅读。聊记于此。

  47、邹恒甫主编:《金融丛书系列》:以让拉丰《激励理论》为最高水平,其他尚可。

  48、中国社会科学出版社《当代经济学教科书译丛》系列:目前国内所见最好教材系列,学完这个系列,建议找老师报考研究生进一步学习。

  

  还有Greene的《计量经济分析》,Hamilton的《时间序列分析》,Campbell等的《金融市场计量经济学》,Chew的《公司治理的革命》都是高级课程的精品。
本文来自: 人大经济论坛 详细出处参考:http://www.pinggu.org/bbs/viewthread.php?tid=314955&page=1

看不懂的vm备份脚本

转自http://communities.vmware.com/docs/DOC-8760

 

ghettoVCB.sh – Free alternative for backing up VM’s for ESX(i) 3.5, 4.x & 5.x

版本 81  单击查看文档历史记录
创建于: 2008-11-17 下午7:04 作者 lamw – 最后修改:  2013-1-26 下午3:58 作者 lamw

Table of Contents:

    • Description
    • Features
    • Requirements
    • Setup
    • Configurations
    • Usage
    • Sample Execution
      • Dry run Mode
      • Debug backup Mode
      • Backup VMs stored in a list
      • Backup All VMs residing on specific ESX(i) host
      • Backup All VMs residing on specific ESX(i) host and exclude the VMs in the exclusion list
      • Backup VMs using individual backup policies
    • Enable compression for backups
    • Email Backup Logs
    • Restore backups (ghettoVCB-restore.sh)
    • Cronjob FAQ
    • Stopping ghettoVCB Process
    • FAQ
    • Our NFS Server Configuration
    • Useful Links
    • Change Log

 

Description:

This script performs backups of virtual machines residing on ESX(i) 3.5/4.x/5.x servers using methodology similar toVMware’s VCB tool. The script takes snapshots of live running virtual machines, backs up the  master VMDK(s) and then upon completion, deletes the snapshot until the next backup. The only caveat is that it utilizes resources available to the Service Console of the ESX server or Busybox Console (Tech Support Mode) of the ESXi server  running the backups as opposed to following the traditional method of offloading virtual machine backups through a VCB proxy.

This script has been tested on ESX 3.5/4.x/5.x and ESXi 3.5/4.x/5.x and supports the following backup mediums: LOCAL STORAGESAN and NFS. The script is non-interactive and can be setup to run via cron. Currently, this script accepts a text file that lists the display names of virtual machine(s) that are to be backed up. Additionally, one can specify a folder containing configuration files on a per VM basis for  granular control over backup policies.

Additionally, for ESX(i) environments that don’t have persistent NFS datastores designated for backups, the script offers the ability to automatically connect the ESX(i) server to a NFS exported folder and then upon backup completion, disconnect it from the ESX(i) server. The connection is established by creating an NFS datastore link which enables monolithic (or thick) VMDK backups as opposed to using the usual  *nix mount command which necessitates breaking VMDK files into the 2gbsparse format for backup. Enabling this mode is self-explanatory and will evidently be so when editing the script (Note: VM_BACKUP_VOLUME variable is ignored if ENABLE_NON_PERSISTENT_NFS=1 ).

In its current configuration, the script will allow up to 3 unique backups of the Virtual Machine before it will overwrite the previous backups; this however, can be modified to fit procedures if need be. Please be diligent in running the script in a test or staging environment before using it on production live Virtual Machines; this script functions well within our environment but there is a chance that  it may not fit well into other environments.

 

If you have any questions, you may post in the dedicated ghettoVCB VMTN community group.

 

If you have found this script to be useful and would like to contribute back, please click here to donate.

 

Please read ALL documentation + FAQ’s before posting a question about an issue or problem. Thank You

Features

  • Online back up of VM(s)
  • Support for multiple VMDK disk(s) backup per VM
  • Only valid VMDK(s) presented to the VM will be backed up
  • Ability to shutdown guestOS and initiate backup process and power on VM afterwards with the option of hard power timeout
  • Allow spaces in VM(s) backup list (not recommended and not a best practice)
  • Ensure that snapshot removal process completes prior to to continuing onto the next VM backup
  • VM(s) that intially contain snapshots will not be backed up and will be ignored
  • Ability to specify the number of backup rotations for VM
  • Output back up VMDK(s) in either ZEROEDTHICK (default behavior) or 2GB SPARSE or THIN or EAGERZEROEDTHICKformat
  • Support for both SCSI and IDE disks
  • Non-persistent NFS backup
  • Fully support VMDK(s) stored across multiple datastores
  • Ability to compress backups (Experimental Support – Please refer to FAQ #25)
  • Ability to configure individual VM backup policies
  • Ability to include/exclude specific VMDK(s) per VM (requires individual VM backup policy setup)
  • Ability to configure logging output to file
  • Independent disk awareness (will ignore VMDK)
  • New timeout variables for shutdown and snapshot creations
  • Ability to configure snapshots with both memory and/or quiesce options
  • Ability to configure disk adapter format
  • Additional debugging information including dry run execution
  • Support for VMs with both virtual/physical RDM (pRDM will be ignored and not backed up)
  • Support for global ghettoVCB configuration file
  • Support for VM exclusion list
  • Ability to backup all VMs residing on a specific host w/o specifying VM list
  • Implemented simple locking mechenism to ensure only 1 instance of ghettoVCB is running per host
  • Updated backup directory structure – rsync friendly
  • Additional logging and final status output
  • Logging of ghettoVCB PID (proces id)
  • Email backup logs (Experimental Suppport)
  • Rsync “Link” Support (Experimental Suppport)
  • Enhanced “dryrun” details including configuration and/or VMDK(s) issues
  • New storage debugging details pre/post backup
  • Quick email status summary
  • Updated ghettoVCB documentation
  • ghettoVCB available via github
  • Support for ESXi 5.1 NEW!
  • Support for individual VM backup via command-line NEW!
  • Support VM(s) with existing snapshots NEW!
  • Support mulitple running instances of ghettoVCB NEW!
    (Experimental Suppport)
  • Configure VM shutdown/startup order NEW!
  • Support changing custom VM name during restore NEW!

 


 

Requirements:

  • VMs running on ESX(i) 3.5/4.x+/5.x
  • SSH console access to ESX(i) host

 


 

Setup:

1) Download ghettoVCB from github by clicking on the ZIP button at the top and upload to either your ESX or ESXi system (use scp or WinSCP to transfer the file)

2) Extract the contents of the zip file (filename will vary):

# unzip ghettoVCB-master.zip

Archive:  ghettoVCB-master.zip
   creating: ghettoVCB-master/
  inflating: ghettoVCB-master/README
  inflating: ghettoVCB-master/ghettoVCB-restore.sh
  inflating: ghettoVCB-master/ghettoVCB-restore_vm_restore_configuration_template
  inflating: ghettoVCB-master/ghettoVCB-vm_backup_configuration_template
  inflating: ghettoVCB-master/ghettoVCB.conf
  inflating: ghettoVCB-master/ghettoVCB.sh

3) The script is now ready to be used and is located in a directory named ghettoVCB-master

# ls -l

-rw-r--r--    1 root     root           281 Jan  6 03:58 README
-rw-r--r--    1 root     root         16024 Jan  6 03:58 ghettoVCB-restore.sh
-rw-r--r--    1 root     root           309 Jan  6 03:58 ghettoVCB-restore_vm_restore_configuration_template
-rw-r--r--    1 root     root           356 Jan  6 03:58 ghettoVCB-vm_backup_configuration_template
-rw-r--r--    1 root     root           631 Jan  6 03:58 ghettoVCB.conf
-rw-r--r--    1 root     root         49375 Jan  6 03:58 ghettoVCB.sh

4) Before using the scripts, you will need to enable the execute permission  on both ghettoVCB.sh and ghettoVCB-restore.sh by running the following:

chmod +x ghettoVCB.shchmod +x ghettoVCB-restore.sh

 


 

Configurations:

The following variables need to be defined within the script or in VM backup policy prior to execution.

Defining the backup datastore and folder in which the backups are stored (if folder does not exist, it will automatically be created):

VM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS

Defining the backup disk format (zeroedthick, eagerzeroedthick, thin, and 2gbsparse are available):

DISK_BACKUP_FORMAT=thin

Note: If you are using the 2gbsparse on an ESXi 5.1 host, backups may fail. Please download the latest version of the ghettoVCB script which automatically resolves this or take a look at this article for the details.

Defining the backup rotation per VM:

VM_BACKUP_ROTATION_COUNT=3

Defining whether the VM is powered down or not prior to backup (1 = enable, 0 = disable):

Note: VM(s) that are powered off will not require snapshoting

POWER_VM_DOWN_BEFORE_BACKUP=0

Defining whether the VM can be hard powered off when  “POWER_VM_DOWN_BEFORE_BACKUP” is enabled and VM does not have VMware  Tools installed

ENABLE_HARD_POWER_OFF=0

If “ENABLE_HARD_POWER_OFF” is enabled, then this defines the number  of (60sec) iterations the script will before executing a hard power off  when:

ITER_TO_WAIT_SHUTDOWN=3

The number (60sec) iterations the script will wait when powering off  the VM and will give up and ignore the particular VM for backup:

POWER_DOWN_TIMEOUT=5

The number (60sec) iterations the script will wait when taking a  snapshot of a VM and will give up and ignore the particular VM for  backup:

Note: Default value should suffice

SNAPSHOT_TIMEOUT=15

Defining whether or not to enable compression (1 = enable, 0 = disable):

ENABLE_COMPRESSION=0

NOTE: With ESXi 3.x/4.x/5.x, there is a limitation of the maximum size of a VM for compression within the unsupported Busybox Console which should not affect backups running classic ESX 3.x,4.x or 5.x. On ESXi 3.x the largest supported VM is 4GB for compression and on ESXi 4.x the largest  supported VM is 8GB. If you try to compress a larger VM, you may run into issues when trying to extract upon a restore. PLEASE TEST THE RESTORE PROCESS BEFORE MOVING TO PRODUCTION SYSTEMS!

Defining the adapter type for backed up VMDK (DEPERCATED – NO LONGER NEEDED):

ADAPTER_FORMAT=buslogic

Defining whether virtual machine memory is snapped and if quiescing is enabled (1 = enable, 0 = disable):

Note: By default both are disabled

VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0

NOTE: VM_SNAPSHOT_MEMORY is only used to ensure when the snapshot is taken, it’s memory contents  are also captured. This is only relevant to the actual snapshot and it’s  not used in any shape/way/form in regards to the backup. All backups  taken whether your VM is running or offline will result in an offline VM  backup when you restore. This was originally added for debugging  purposes and in generally should be left disabled

Defining VMDK(s) to backup from a particular VM either a list of vmdks or “all”

VMDK_FILES_TO_BACKUP="myvmdk.vmdk"

 

Defining whether or not VM(s) with existing snapshots can be backed up. This flag means it will CONSOLIDATE ALL EXISTING SNAPSHOTS for a VM prior to starting the backup (1 = yes, 0 = no):

ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0

 

Defining the order of which VM(s) should be shutdown first, especially if there is a dependency between multiple VM(s). This should be a comma seperate list of VM(s)

VM_SHUTDOWN_ORDER=vm1,vm2,vm3

 

Defining the order of VM(s) that should be started up first after backups have completed, especially if there is a dependency between multiple VM(s). This should be a comma seperate list of VM(s)

VM_STARTUP_ORDER=vm3,vm2,vm1

 

 

Defining NON-PERSISTENT NFS Backup Volume (1 = yes, 0 = no):

ENABLE_NON_PERSISTENT_NFS=0

NOTE: This is meant for environments that do not want a persisted connection to their NFS backup volume and allows the NFS volume to only be mounted during backups. The script expects the following 5 variables to be defined if this is to be used: UNMOUNT_NFS, NFS_SERVER, NFS_MOUNT, NFS_LOCAL_NAME and NFS_VM_BACKUP_DIR

 

Defining whether or not to unmount the NFS backup volume (1 = yes, 0 = no):

UNMOUNT_NFS=0

Defining the NFS server address (IP/hostname):

NFS_SERVER=172.51.0.192

Defining the NFS export path:

NFS_MOUNT=/upload

Defining the NFS datastore name:

NFS_LOCAL_NAME=backup

Defining the NFS backup directory for VMs:

NFS_VM_BACKUP_DIR=mybackups

 

NOTE: Only supported if you are running vSphere 4.1 and this feature is experimental. If you are having issues with sending mail, please take a look at Email Backup Log section

Defining whether or not to email backup logs (1 = yes, 0 = no):

EMAIL_LOG=1

Defining whether or not to email message will be deleted off the host  whether it is successful in sending, this is used for debugging  purposes. (1 = yes, 0 = no):

EMAIL_DEBUG=1

Defining email server:

EMAIL_SERVER=auroa.primp-industries.com

Defining email server port:

EMAIL_SERVER_PORT=25

 

Defining email delay interval (useful if you have slow SMTP server and would like to include a delay in netcat using -i param, default is 1second):

EMAIL_DELAY_INTERVAL=1

Defining recipient of the email:

EMAIL_TO=auroa@primp-industries.com

Defining from user which may require specific domain entry depending on email server configurations:

EMAIL_FROM=root@ghettoVCB

 

Defining to support RSYNC symbolic link creation (1 = yes, 0 = no):

RSYNC_LINK=0

 

Note: This  enables an automatic creation of a generic symbolic link (both a  relative & absolution path) in which users can refer to run  replication backups using rsync from a remote host. This does not  actually support rsync backups with ghettoVCB. Please take a look at the  Rsync Section of the documentation for more details.

 

  • A sample global ghettoVCB configuration file is included with the download called ghettoVCB.conf.  It contains the same variables as defined from above and allows a user  to customize and define multiple global configurations based on a user’s  environment.

 

# cat ghettoVCB.conf 
VM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0
ENABLE_NON_PERSISTENT_NFS=0
UNMOUNT_NFS=0
NFS_SERVER=172.30.0.195
NFS_MOUNT=/nfsshare
NFS_LOCAL_NAME=nfs_storage_backup
NFS_VM_BACKUP_DIR=mybackups
SNAPSHOT_TIMEOUT=15
EMAIL_LOG=0
EMAIL_SERVER=auroa.primp-industries.com
EMAIL_SERVER_PORT=25
EMAIL_DELAY_INTERVAL=1
EMAIL_TO=auroa@primp-industries.com
EMAIL_FROM=root@ghettoVCB
WORKDIR_DEBUG=0
VM_SHUTDOWN_ORDER=
VM_STARTUP_ORDER=

To override any existing configurations within the ghettoVCB.sh script  and to use a global configuration file, user just needs to specify the  new flag -g and path to global configuration file (For an example,  please refer to the sample execution section of the documenation)

 

Running multiple instances of ghettoVCB is now supported with the latest release by specifying the working directory (-w) flag.

By default, the working directory of the ghettoVCB instance is /tmp/ghettoVCB.work and you can run another instance by providing an alternate working directory. You should try to minimize the number of ghettoVCB instances running on your ESXi host as it does consume some amount of resources when running in the ESXi Shell. This is considered an experimental feature, so please test in a development environment to ensure everything is working prior to moving to production system.

 

Ensure that you do not edit past this section:

########################## DO NOT MODIFY PAST THIS LINE ##########################

 


 

Usage:

# ./ghettoVCB.sh 
###############################################################################
#
# ghettoVCB for ESX/ESXi 3.5, 4.x+ and 5.x
# Author: William Lam
# http://www.virtuallyghetto.com/
# Documentation: http://communities.vmware.com/docs/DOC-8760
# Created: 11/17/2008
# Last modified: 2012_12_17 Version 0
#
###############################################################################

Usage: ghettoVCB.sh [options]

OPTIONS:
   -a     Backup all VMs on host
   -f     List of VMs to backup
   -m     Name of VM to backup (overrides -f)
   -c     VM configuration directory for VM backups
   -g     Path to global ghettoVCB configuration file
   -l     File to output logging
   -w     ghettoVCB work directory (default: )
   -d     Debug level [info|debug|dryrun] (default: info)

(e.g.)

Backup VMs stored in a list
    ./ghettoVCB.sh -f vms_to_backup

Backup a single VM
    ./ghettoVCB.sh -m vm_to_backup

Backup all VMs residing on this host
    ./ghettoVCB.sh -a

Backup all VMs residing on this host except for the VMs in the exclusion list
    ./ghettoVCB.sh -a -e vm_exclusion_list

Backup VMs based on specific configuration located in directory
    ./ghettoVCB.sh -f vms_to_backup -c vm_backup_configs

Backup VMs using global ghettoVCB configuration file
    ./ghettoVCB.sh -f vms_to_backup -g /global/ghettoVCB.conf

Output will log to /tmp/ghettoVCB.log (consider logging to local or remote datastore to persist logs)
    ./ghettoVCB.sh -f vms_to_backup -l /vmfs/volume/local-storage/ghettoVCB.log

Dry run (no backup will take place)
    ./ghettoVCB.sh -f vms_to_backup -d dryrun

The input to this script is a file that contains the display name of the  virtual machine(s) separated by a newline. When creating this file on a  non-Linux/UNIX system, you may introduce ^M character which can cause  the script to miss-behave. To ensure this does not occur, plesae create  the file on the ESX/ESXi host.

Here is a sample of what the file would look like:

[root@himalaya ~]# cat vms_to_backup
vCOPS
vMA
vCloudConnector

 


 

Sample Execution:

  • Dry run Mode
  • Debug Mode
  • Backup VMs stored in a list
  • Backup Single VM using command-line
  • Backup All VMs residing on specific ESX(i) host
  • Backup VMs based on individual VM backup policies

 

Dry run Mode (no backup will take place)

Note: This execution mode provides a qucik summary of details on whether a given set of VM(s)/VMDK(s) will be backed up. It provides additional information such as VMs that may have snapshots, VMDK(s) that are configured as independent disks, or other issues that may cause a VM or VMDK to not backed up.

 

  • Log verbosity: dryrun
  • Log output: stdout & /tmp (default)
    • Logs by default will be stored in /tmp, these log files may not persist through reboots, especially when dealing with ESXi. You should log to either a local or remote datastore to ensure that logs are kept upon a reboot.
[root@himalaya ghettoVCB]# ./ghettoVCB.sh -f vms_to_backup -d dryrun
Logging output to "/tmp/ghettoVCB-2011-03-13_15-19-57.log" ...
2011-03-13 15:19:57 -- info: ============================== ghettoVCB LOG START ==============================

2011-03-13 15:19:57 -- info: CONFIG - VERSION = 2011_03_13_1
2011-03-13 15:19:57 -- info: CONFIG - GHETTOVCB_PID = 30157
2011-03-13 15:19:57 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2011-03-13 15:19:57 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2011-03-13 15:19:57 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-19-57
2011-03-13 15:19:57 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2011-03-13 15:19:57 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2011-03-13 15:19:57 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2011-03-13 15:19:57 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2011-03-13 15:19:57 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2011-03-13 15:19:57 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2011-03-13 15:19:57 -- info: CONFIG - LOG_LEVEL = dryrun
2011-03-13 15:19:57 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2011-03-13_15-19-57.log
2011-03-13 15:19:57 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2011-03-13 15:19:57 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2011-03-13 15:19:57 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2011-03-13 15:19:57 -- info: CONFIG - EMAIL_LOG = 0
2011-03-13 15:19:57 -- info:
2011-03-13 15:19:57 -- dryrun: ###############################################
2011-03-13 15:19:57 -- dryrun: Virtual Machine: scofield
2011-03-13 15:19:57 -- dryrun: VM_ID: 704
2011-03-13 15:19:57 -- dryrun: VMX_PATH: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield.vmx
2011-03-13 15:19:57 -- dryrun: VMX_DIR: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield
2011-03-13 15:19:57 -- dryrun: VMX_CONF: scofield/scofield.vmx
2011-03-13 15:19:57 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage
2011-03-13 15:19:57 -- dryrun: VMDK(s):
2011-03-13 15:19:58 -- dryrun:  scofield_3.vmdk 3 GB
2011-03-13 15:19:58 -- dryrun:  scofield_2.vmdk 2 GB
2011-03-13 15:19:58 -- dryrun:  scofield_1.vmdk 1 GB
2011-03-13 15:19:58 -- dryrun:  scofield.vmdk   5 GB
2011-03-13 15:19:58 -- dryrun: INDEPENDENT VMDK(s):
2011-03-13 15:19:58 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 11 GB
2011-03-13 15:19:58 -- dryrun: ###############################################

2011-03-13 15:19:58 -- dryrun: ###############################################
2011-03-13 15:19:58 -- dryrun: Virtual Machine: vMA
2011-03-13 15:19:58 -- dryrun: VM_ID: 1440
2011-03-13 15:19:58 -- dryrun: VMX_PATH: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vMA/vMA.vmx
2011-03-13 15:19:58 -- dryrun: VMX_DIR: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vMA
2011-03-13 15:19:58 -- dryrun: VMX_CONF: vMA/vMA.vmx
2011-03-13 15:19:58 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage
2011-03-13 15:19:58 -- dryrun: VMDK(s):
2011-03-13 15:19:58 -- dryrun:  vMA-000002.vmdk 5 GB
2011-03-13 15:19:58 -- dryrun: INDEPENDENT VMDK(s):
2011-03-13 15:19:58 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 5 GB
2011-03-13 15:19:58 -- dryrun: Snapshots found for this VM, please commit all snapshots before continuing!
2011-03-13 15:19:58 -- dryrun: THIS VIRTUAL MACHINE WILL NOT BE BACKED UP DUE TO EXISTING SNAPSHOTS!
2011-03-13 15:19:58 -- dryrun: ###############################################

2011-03-13 15:19:58 -- dryrun: ###############################################
2011-03-13 15:19:58 -- dryrun: Virtual Machine: vCloudConnector
2011-03-13 15:19:58 -- dryrun: VM_ID: 2064
2011-03-13 15:19:58 -- dryrun: VMX_PATH: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector/vCloudConnector.vmx
2011-03-13 15:19:58 -- dryrun: VMX_DIR: /vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector
2011-03-13 15:19:58 -- dryrun: VMX_CONF: vCloudConnector/vCloudConnector.vmx
2011-03-13 15:19:58 -- dryrun: VMFS_VOLUME: himalaya-local-SATA.RE4-GP:Storage
2011-03-13 15:19:58 -- dryrun: VMDK(s):
2011-03-13 15:19:59 -- dryrun:  vCloudConnector.vmdk    3 GB
2011-03-13 15:19:59 -- dryrun: INDEPENDENT VMDK(s):
2011-03-13 15:19:59 -- dryrun:  vCloudConnector_1.vmdk  40 GB
2011-03-13 15:19:59 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 3 GB
2011-03-13 15:19:59 -- dryrun: Snapshots can not be taken for indepdenent disks!
2011-03-13 15:19:59 -- dryrun: THIS VIRTUAL MACHINE WILL NOT HAVE ALL ITS VMDKS BACKED UP!
2011-03-13 15:19:59 -- dryrun: ###############################################

2011-03-13 15:19:59 -- info: ###### Final status: OK, only a dryrun. ######

2011-03-13 15:19:59 -- info: ============================== ghettoVCB LOG END ================================

In the example above, we have 3 VMs to be backed up:

  • scofield has 4 VMDK(s) that total up to 11GB and does not contain any snapshots/independent disks and this VM should backup without any issues
  • vMA has 1 VMDK but it also contains a snapshot and clearly this VM will not be backed up until the snapshot has been committed
  • vCloudConnector has 2 VMDK(s), one which is 3GB and another which is 40GB and configured as an independent disk. Since snapshots do not affect independent disk, only the 3GB VMDK will be backed up for this VM as denoted by the “TOTAL_VM_SIZE_TO_BACKUP

Debug backup mode

Note: This execution modes provides more in-depth information about environment/backup process including additional storage debugging information which provides information about both the source/destination datastore pre and post backups. This can be very useful in troubleshooting backups

 

  • Log verbosity: debug
  • Log output: stdout & /tmp (default)
    • Logs by default will be stored in /tmp, these log files may not persist  through reboots, especially when dealing with ESXi. You should log to  either a local or remote datastore to ensure that logs are kept upon a  reboot.
[root@himalaya ghettoVCB]# ./ghettoVCB.sh -f vms_to_backup -d debug
Logging output to "/tmp/ghettoVCB-2011-03-13_15-27-59.log" ...
2011-03-13 15:27:59 -- info: ============================== ghettoVCB LOG START ==============================

2011-03-13 15:27:59 -- debug: Succesfully acquired lock directory - /tmp/ghettoVCB.lock

2011-03-13 15:27:59 -- debug: HOST VERSION: VMware ESX 4.1.0 build-260247
2011-03-13 15:27:59 -- debug: HOST LEVEL: VMware ESX 4.1.0 GA
2011-03-13 15:27:59 -- debug: HOSTNAME: himalaya.primp-industries.com

2011-03-13 15:27:59 -- info: CONFIG - VERSION = 2011_03_13_1
2011-03-13 15:27:59 -- info: CONFIG - GHETTOVCB_PID = 31074
2011-03-13 15:27:59 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2011-03-13 15:27:59 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2011-03-13 15:27:59 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-27-59
2011-03-13 15:27:59 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2011-03-13 15:27:59 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2011-03-13 15:27:59 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2011-03-13 15:27:59 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2011-03-13 15:27:59 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2011-03-13 15:27:59 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2011-03-13 15:27:59 -- info: CONFIG - LOG_LEVEL = debug
2011-03-13 15:27:59 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2011-03-13_15-27-59.log
2011-03-13 15:27:59 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2011-03-13 15:27:59 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2011-03-13 15:27:59 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2011-03-13 15:27:59 -- info: CONFIG - EMAIL_LOG = 0
2011-03-13 15:27:59 -- info:
2011-03-13 15:28:01 -- debug: Storage Information before backup:
2011-03-13 15:28:01 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage
2011-03-13 15:28:01 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB
2011-03-13 15:28:01 -- debug: SRC_DATASTORE_FREE: 539.4 GB
2011-03-13 15:28:01 -- debug: SRC_DATASTORE_BLOCKSIZE: 4
2011-03-13 15:28:01 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB
2011-03-13 15:28:01 -- debug:
2011-03-13 15:28:01 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups
2011-03-13 15:28:01 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB
2011-03-13 15:28:01 -- debug: DST_DATASTORE_FREE: 296.8 GB
2011-03-13 15:28:01 -- debug: DST_DATASTORE_BLOCKSIZE: NA
2011-03-13 15:28:01 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA
2011-03-13 15:28:01 -- debug:
2011-03-13 15:28:02 -- info: Initiate backup for scofield
2011-03-13 15:28:02 -- debug: /usr/sbin/vmkfstools -i "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_3.vmdk" -a "buslogic" -d "thin" "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/scofield/scofield-2011-03-13_15-27-59/scofield_3.vmdk"
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_3.vmdk'...
Clone: 37% done.
2011-03-13 15:28:04 -- debug: /usr/sbin/vmkfstools -i "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_2.vmdk" -a "buslogic" -d "thin" "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/scofield/scofield-2011-03-13_15-27-59/scofield_2.vmdk"
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_2.vmdk'...
Clone: 85% done.
2011-03-13 15:28:05 -- debug: /usr/sbin/vmkfstools -i "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_1.vmdk" -a "buslogic" -d "thin" "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/scofield/scofield-2011-03-13_15-27-59/scofield_1.vmdk"

2011-03-13 15:28:06 -- debug: /usr/sbin/vmkfstools -i "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield.vmdk" -a "buslogic" -d "thin" "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/scofield/scofield-2011-03-13_15-27-59/scofield.vmdk"
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield.vmdk'...
Clone: 78% done.
2011-03-13 15:29:52 -- info: Backup Duration: 1.83 Minutes
2011-03-13 15:29:52 -- info: Successfully completed backup for scofield!

2011-03-13 15:29:54 -- debug: Storage Information after backup:
2011-03-13 15:29:54 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage
2011-03-13 15:29:54 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB
2011-03-13 15:29:54 -- debug: SRC_DATASTORE_FREE: 539.4 GB
2011-03-13 15:29:54 -- debug: SRC_DATASTORE_BLOCKSIZE: 4
2011-03-13 15:29:54 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB
2011-03-13 15:29:54 -- debug:
2011-03-13 15:29:54 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups
2011-03-13 15:29:54 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB
2011-03-13 15:29:54 -- debug: DST_DATASTORE_FREE: 296.8 GB
2011-03-13 15:29:54 -- debug: DST_DATASTORE_BLOCKSIZE: NA
2011-03-13 15:29:54 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA
2011-03-13 15:29:54 -- debug:
2011-03-13 15:29:55 -- debug: Storage Information before backup:
2011-03-13 15:29:55 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage
2011-03-13 15:29:55 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB
2011-03-13 15:29:55 -- debug: SRC_DATASTORE_FREE: 539.4 GB
2011-03-13 15:29:55 -- debug: SRC_DATASTORE_BLOCKSIZE: 4
2011-03-13 15:29:55 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB
2011-03-13 15:29:55 -- debug:
2011-03-13 15:29:55 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups
2011-03-13 15:29:55 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB
2011-03-13 15:29:55 -- debug: DST_DATASTORE_FREE: 296.8 GB
2011-03-13 15:29:55 -- debug: DST_DATASTORE_BLOCKSIZE: NA
2011-03-13 15:29:55 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA
2011-03-13 15:29:55 -- debug:
2011-03-13 15:29:55 -- info: Snapshot found for vMA, backup will not take place

2011-03-13 15:29:57 -- debug: Storage Information before backup:
2011-03-13 15:29:57 -- debug: SRC_DATASTORE: himalaya-local-SATA.RE4-GP:Storage
2011-03-13 15:29:57 -- debug: SRC_DATASTORE_CAPACITY: 1830.5 GB
2011-03-13 15:29:57 -- debug: SRC_DATASTORE_FREE: 539.4 GB
2011-03-13 15:29:57 -- debug: SRC_DATASTORE_BLOCKSIZE: 4
2011-03-13 15:29:57 -- debug: SRC_DATASTORE_MAX_FILE_SIZE: 1024 GB
2011-03-13 15:29:57 -- debug:
2011-03-13 15:29:57 -- debug: DST_DATASTORE: dlgCore-NFS-bigboi.VM-Backups
2011-03-13 15:29:57 -- debug: DST_DATASTORE_CAPACITY: 1348.4 GB
2011-03-13 15:29:57 -- debug: DST_DATASTORE_FREE: 296.8 GB
2011-03-13 15:29:57 -- debug: DST_DATASTORE_BLOCKSIZE: NA
2011-03-13 15:29:57 -- debug: DST_DATASTORE_MAX_FILE_SIZE: NA
2011-03-13 15:29:57 -- debug:
2011-03-13 15:29:58 -- info: Initiate backup for vCloudConnector
2011-03-13 15:29:58 -- debug: /usr/sbin/vmkfstools -i "/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector/vCloudConnector.vmdk" -a "buslogic" -d "thin" "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vCloudConnector/vCloudConnector-2011-03-13_15-27-59/vCloudConnector.vmdk"
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector/vCloudConnector.vmdk'...
Clone: 97% done.
2011-03-13 15:30:45 -- info: Backup Duration: 47 Seconds
2011-03-13 15:30:45 -- info: WARN: vCloudConnector has some Independent VMDKs that can not be backed up!

2011-03-13 15:30:45 -- info: ###### Final status: ERROR: Only some of the VMs backed up, and some disk(s) failed! ######

2011-03-13 15:30:45 -- debug: Succesfully removed lock directory - /tmp/ghettoVCB.lock

2011-03-13 15:30:45 -- info: ============================== ghettoVCB LOG END ================================

Backup VMs stored in a list

[root@himalaya ~]# ./ghettoVCB.sh -f vms_to_backup

Backup Single VM using command-line

# ./ghettoVCB.sh -m MyVM

Backup All VMs residing on specific ESX(i) host

/ghettoVCB # ./ghettoVCB.sh -a

Backup All VMs residing on specific ESX(i) host and exclude the VMs in the exclusion list

/ghettoVCB # ./ghettoVCB.sh -a -e vm_exclusion_list

 

Backup VMs based on individual VM backup policies and log output to /tmp/ghettoVCB.log

  • Log verbosity: info (default)
  • Log output: /tmp/ghettoVCB.log
    • Logs by default will be stored in /tmp, these log files may not persist  through reboots, especially when dealing with ESXi. You should log to  either a local or remote datastore to ensure that logs are kept upon a  reboot.

1. Create folder to hold individual VM backup policies (can be named anything):

[root@himalaya ~]# mkdir backup_config

2. Create individual VM backup policies for each VM that ensure each  file is named exactly as the display name of the VM being backed up (use  provided template to create duplicates):

[root@himalaya backup_config]# cp ghettoVCB-vm_backup_configuration_template scofield
[root@himalaya backup_config]# cp ghettoVCB-vm_backup_configuration_template vCloudConnector

Listing of VM backup policy within backup configuration directory

[root@himalaya backup_config]# ls
ghettoVCB-vm_backup_configuration_template  scofield  vCloudConnector  

Backup policy for “scofield” (backup only 2 specific VMDKs)

[root@himalaya backup_config]# cat scofield
VM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=4
POWER_DOWN_TIMEOUT=5
SNAPSHOT_TIMEOUT=15
ENABLE_COMPRESSION=0
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
VMDK_FILES_TO_BACKUP="scofield_2.vmdk,scofield_1.vmdk"

Backup policy for VM “vCloudConnector” (backup all VMDKs found)

[root@himalaya backup_config]# cat vCloudConnector
VM_BACKUP_VOLUME=/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=4
POWER_DOWN_TIMEOUT=5
SNAPSHOT_TIMEOUT=15
ENABLE_COMPRESSION=0
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
VMDK_FILES_TO_BACKUP="vCloudConnector.vmdk"

Note: When specifying -c option (individual VM backup policy mode) if a VM is listed in the backup list but DOES NOT have a corresponding backup policy, the VM will be backed up using the  default configuration found within the ghettoVCB.sh script.

Execution of backup

[root@himalaya ~]# ./ghettoVCB.sh -f vms_to_backup -c backup_config -l /tmp/ghettoVCB.log

2011-03-13 15:40:50 -- info: ============================== ghettoVCB LOG START ==============================

2011-03-13 15:40:51 -- info: CONFIG - USING CONFIGURATION FILE = backup_config//scofield
2011-03-13 15:40:51 -- info: CONFIG - VERSION = 2011_03_13_1
2011-03-13 15:40:51 -- info: CONFIG - GHETTOVCB_PID = 2967
2011-03-13 15:40:51 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2011-03-13 15:40:51 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2011-03-13 15:40:51 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-40-50
2011-03-13 15:40:51 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2011-03-13 15:40:51 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2011-03-13 15:40:51 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2011-03-13 15:40:51 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4
2011-03-13 15:40:51 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2011-03-13 15:40:51 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2011-03-13 15:40:51 -- info: CONFIG - LOG_LEVEL = info
2011-03-13 15:40:51 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB.log
2011-03-13 15:40:51 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2011-03-13 15:40:51 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2011-03-13 15:40:51 -- info: CONFIG - VMDK_FILES_TO_BACKUP = scofield_2.vmdk,scofield_1.vmdk
2011-03-13 15:40:51 -- info: CONFIG - EMAIL_LOG = 0
2011-03-13 15:40:51 -- info:
2011-03-13 15:40:53 -- info: Initiate backup for scofield
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_2.vmdk'...
Clone: 100% done.

Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/scofield/scofield_1.vmdk'...
Clone: 100% done.

2011-03-13 15:40:55 -- info: Backup Duration: 2 Seconds
2011-03-13 15:40:55 -- info: Successfully completed backup for scofield!

2011-03-13 15:40:57 -- info: CONFIG - VERSION = 2011_03_13_1
2011-03-13 15:40:57 -- info: CONFIG - GHETTOVCB_PID = 2967
2011-03-13 15:40:57 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2011-03-13 15:40:57 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2011-03-13 15:40:57 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-40-50
2011-03-13 15:40:57 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2011-03-13 15:40:57 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2011-03-13 15:40:57 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2011-03-13 15:40:57 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2011-03-13 15:40:57 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2011-03-13 15:40:57 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2011-03-13 15:40:57 -- info: CONFIG - LOG_LEVEL = info
2011-03-13 15:40:57 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB.log
2011-03-13 15:40:57 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2011-03-13 15:40:57 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2011-03-13 15:40:57 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2011-03-13 15:40:57 -- info: CONFIG - EMAIL_LOG = 0
2011-03-13 15:40:57 -- info:
2011-03-13 15:40:59 -- info: Snapshot found for vMA, backup will not take place

2011-03-13 15:40:59 -- info: CONFIG - USING CONFIGURATION FILE = backup_config//vCloudConnector
2011-03-13 15:40:59 -- info: CONFIG - VERSION = 2011_03_13_1
2011-03-13 15:40:59 -- info: CONFIG - GHETTOVCB_PID = 2967
2011-03-13 15:40:59 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS
2011-03-13 15:40:59 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2011-03-13 15:40:59 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2011-03-13_15-40-50
2011-03-13 15:40:59 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2011-03-13 15:40:59 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2011-03-13 15:40:59 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2011-03-13 15:40:59 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 4
2011-03-13 15:40:59 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2011-03-13 15:40:59 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2011-03-13 15:40:59 -- info: CONFIG - LOG_LEVEL = info
2011-03-13 15:40:59 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB.log
2011-03-13 15:40:59 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2011-03-13 15:40:59 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2011-03-13 15:40:59 -- info: CONFIG - VMDK_FILES_TO_BACKUP = vCloudConnector.vmdk
2011-03-13 15:40:59 -- info: CONFIG - EMAIL_LOG = 0
2011-03-13 15:40:59 -- info:
2011-03-13 15:41:01 -- info: Initiate backup for vCloudConnector
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage/vCloudConnector/vCloudConnector.vmdk'...
Clone: 100% done.

2011-03-13 15:41:51 -- info: Backup Duration: 50 Seconds
2011-03-13 15:41:51 -- info: WARN: vCloudConnector has some Independent VMDKs that can not be backed up!

2011-03-13 15:41:51 -- info: ###### Final status: ERROR: Only some of the VMs backed up, and some disk(s) failed! ######

2011-03-13 15:41:51 -- info: ============================== ghettoVCB LOG END ================================

 

 


 

Enable compression for backups (EXPERIMENTAL SUPPORT)

Please take a look at FAQ #25 for more details before continuing

To make use of this feature, modify the variable ENABLE_COMPRESSION from 0 to 1. Please note, do not mix uncompressed backups with  compressed backups. Ensure that directories selected for backups do not contain any backups with previous versions of ghettoVCB before enabling  and implementing the compressed backups feature.

 


 

Email Backup Logs (EXPERIMENTAL SUPPORT)

nc (netcat) utility must be present for email support to function, this utility is a now a default with the release of vSphere 4.1 or greater, previous releases of VI 3.5 and/or vSphere 4.0 does not contain this utility. The reason this is listed as experimental is it may not be compatible with all email servers as the script utlizes nc (netcat) utility to communicate to an email server. This feature is  provided as-is with no guarantees. If you enable this feature, a  separate log will be generated along side  any normal logging which will  be used to email recipient. If for whatever reason, the email fails to  send, an entry will appear per the normal logging mechanism.

 

Users should also make note due to limited functionality of netcat, it uses SMTP pipelining which is not the most ideal method of communicating with an SMTP server. Email from ghettoVCB may not work if your email server does not support this feature.

 

You can define an email recipient in the following two ways:

 

EMAIL_TO=william@virtuallyghetto.com

OR

EMAIL_TO=william@virtuallyghetto.com,tuan@virtuallyghetto.com

 

If you are running ESXi 5.1, you will need to create a custom firewall rule to allow your email traffic to go out which I will assume is default port 25. Here are the steps for creating a custom email rule.

 

Step 1 – Create a file called /etc/vmware/firewall/email.xml with contains the following:

<ConfigRoot>
  <service>
    <id>email</id>
    <rule id="0000">
      <direction>outbound</direction>
      <protocol>tcp</protocol>
      <porttype>dst</porttype>
      <port>25</port>
    </rule>
    <enabled>true</enabled>
    <required>false</required>
  </service>
</ConfigRoot>

 

Step 2 – Reload the ESXi firewall by running the following ESXCLI command:

~ #
esxcli network firewall refresh

Step 3 – Confirm that your email rule has been loaded by running the following ESXCLI command:

~ # esxcli network firewall ruleset list | grep email
email                  true

Step 4 – Connect to your email server by usingn nc (netcat) by running the following command and specifying the IP Address/Port of your email server:

~ # nc 172.30.0.107 25
220 mail.primp-industries.com ESMTP Postfix

You should recieve a response from your email server and you can enter Ctrl+C to exit. This custom ESXi firewall rule will not persist after a reboot, so you should create a custom VIB to ensure it persists after a system reboot. Please take a look at this article for the details.

 


 

Rsync Support  (EXPERIMENTAL SUPPORT)

To make use of this feature, modify the variable RSYNC_LINK from 0  to 1. Please note, this is an experimental feature request from users that rely on rsync to replicate changes from one datastore volume to  another datastore volume. The premise of this feature is to have a standardized folder that rsync can monitor for changes to replicate to  another backup datastore. When this feature is enabled, a symbolic link  will be generated with the format of “<VMNAME>-symlink” and will  reference the latest successful VM backup. You can then rely on this  symbolic link to watch for changes and replicate to your backup  datastore.

Here is an example of what this would look like:

[root@himalaya ghettoVCB]# ls -la /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vcma/
total 0
drwxr-xr-x 1 nobody nobody 110 Sep 27 08:08 .
drwxr-xr-x 1 nobody nobody  17 Sep 16 14:01 ..
lrwxrwxrwx 1 nobody nobody  89 Sep 27 08:08 vcma-symlink -> /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/vcma/vcma-2010-09-27_08-07-37
drwxr-xr-x 1 nobody nobody  58 Sep 27 08:04 vcma-2010-09-27_08-04-26
drwxr-xr-x 1 nobody nobody  58 Sep 27 08:06 vcma-2010-09-27_08-05-55
drwxr-xr-x 1 nobody nobody  58 Sep 27 08:08 vcma-2010-09-27_08-07-37

FYI – This feature has not been tested, please provide feedback if this does not work as expected.


 

Restore backups (ghettoVCB-restore.sh):

To recover a VM that has been processed by ghettoVCB, please take a look at this document: Ghetto Tech Preview – ghettoVCB-restore.sh – Restoring VM’s backed up from ghettoVCB to ESX(i) 3.5, 4.x, and 5.x

 


Stopping ghettoVCB Process:

There may be a situation where you need to stop the ghettoVCB process and entering Ctrl+C will only kill off the main ghettoVCB process, however there may still be other spawn processes that you may need to identify and stop. Below are two scenarios you may encounter and the process to completely stop all processes related to ghettoVCB.

 

Interactively running ghettoVCB:

 

Step 1 – Press Ctrl+C which will kill off the main ghettoVCB instance

 

Step 2 – Search for any existing ghettoVCB process by running the following:

 

# ps -c | grep ghettoVCB | grep -v grep
3360136 3360136 tail                 tail -f /tmp/ghettoVCB.work/ghettovcb.Cs1M1x

 

Step 3 – Here we can see there is a tail command that was used in the script. We need to stop this process by using the kill command which accepts the PID (Process ID) which is identified by the first value on the far left hand side of the command. In this example, it is 3360136.

# kill -9 3360136

 

Note: Make sure you identify the correct PID, else you could accidently impact a running VM or worse your ESXi host.

 

Step 4 – Depending on where you stopped the ghettoVCB process, you may need to consolidate or remove any existing snapshots that may exist on the VM that was being backed up. You can easily do so by using the vSphere Client.

 

Non-Interactively running ghettoVCB:

 

Step 1 – Search for the ghettoVCB process (you can also validate the PID from the logs)

 

~ # ps -c | grep ghettoVCB | grep -v grep
3360393 3360393 busybox              ash ./ghettoVCB.sh -f list -d debug
3360790 3360790 tail                 tail -f /tmp/ghettoVCB.work/ghettovcb.deGeB7

 

Step 2 – Stop both the main ghettoVCB instance & tail command by using the kill command and specifying their respective PID IDs:

 

kill -9 3360393
kill -9 3360790

 

Step 3 – If a VM was in the process of being backed up, there is an additional process for the actual vmkfstools copy. You will need to identify the process for that and kill that as well. We will again use ps -c command and search for any vmkfstools that are running:

# ps -c | grep vmkfstools | grep -v grep
3360796 3360796 vmkfstools           /sbin/vmkfstools -i /vmfs/volumes/himalaya-temporary/VC-Windows/VC-Windows.vmdk -a lsilogic -d thin /vmfs/volumes/test-dont-use-this-volume/backups/VC-Windows/VC-Windows-2013-01-26_16-45-35/VC-Windows.vmdk

 

 

Step 4 – In case there is someone manually running a vmkfstools, make sure you take a look at the command itself and that it maps back to the current VM that was being backed up before kill the process. Once you have identified the proper PID, go ahead and use the kill command:

# kill -9 3360796

 

Step 5 – Depending on where you stopped the  ghettoVCB process, you may need to consolidate or remove any existing  snapshots that may exist on the VM that was being backed up. You can  easily do so by using the vSphere Client.

 


 

Cronjob FAQ:

Please take a moment to read over what is a cronjob and how to set one up, before continuing

The task of configuring cronjobs on classic ESX servers (with Service Console) is no different than traditional cronjobs on *nix operating  systems (this procedure is outlined in the link above). With ESXi on the  other hand, additional factors need to be taken into account when  setting up cronjobs in the limited shell console called Busybox because changes made do not persist through a system reboot. The following document will outline steps to ensure that cronjob configurations are saved and present upon a reboot.

 

Important Note: Always redirect the ghettoVCB output to /dev/null and/or to a log when automating via cron, this becomes very important as one user has identified a limited amount of buffer capacity in which once filled, may cause ghettoVCB to stop in the middle of a backup. This primarily only affects users on ESXi, but it is good practice to always redirect the output. Also ensure you are specifying the FULL PATH when referencing the ghettoVCB script, input or log files.

 

e.g.

0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh -f /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist > /dev/null

or

0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh -f /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist > /tmp/ghettoVCB.log

 

Task: Configure ghettoVCB.sh to execute a backup five days a week (M-F) at 12AM (midnight) everyday and send output to a unique log file

Configure on ESX:

1. As root, you’ll install your cronjob by issuing:

[root@himalaya ~]# crontab -e

2. Append the following entry:

0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh -f /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist > /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB-backup-$(date +\%s).log

3. Save and exit

[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# crontab -e
no crontab for root - using an empty one
crontab: installing new crontab

4. List out and verify the cronjob that was just created:

[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# crontab -l
0 0 * * 1-5 /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB.sh -f /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/backuplist > /vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/ghettoVCB-backup-$(date +\%s).log

You’re ready to go!

Configure on ESXi:

1. Setup the cronjob by appending the following line to /var/spool/cron/crontabs/root:

0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-$(date +\%s).log

 

If you are unable to edit/modify /var/spool/cron/crontabs/root, please make a copy and then edit the copy with the changes

cp /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root.backup

Once your changes have been made, then “mv” the backup to the original file. This may occur on ESXi 4.x or 5.x hosts

mv /var/spool/cron/crontabs/root.backup /var/spool/cron/crontabs/root

You can now verify the crontab entry has been updated by using “cat” utility.
2. Kill the current crond (cron daemon) and then restart the crond for the changes to take affect:

On ESXi < 3.5u3

kill $(ps | grep crond | cut -f 1 -d ' ')

On ESXi 3.5u3+

~ # kill $(pidof crond)
~ # crond

On ESXi 4.x/5.0

~ # kill $(cat /var/run/crond.pid)
~ # busybox crond

 

On ESXi 5.1

~ # kill $(cat /var/run/crond.pid)
~ # crond

3. Now that the cronjob is ready to go, you need to ensure that this  cronjob will persist through a reboot. You’ll need to add the following two lines to /etc/rc.local (ensure that the cron entry matches what was defined above). In ESXi 5.1, you will need to edit /etc/rc.local.d/local.sh instead of /etc/rc.local as that is no longer valid.

On ESXi 3.5

/bin/kill $(pidof crond)
/bin/echo "0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
crond

On ESXi 4.x/5.0

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
/bin/busybox crond

 

On ESXi 5.1

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
crond

Afterwards the file should look like the following:

~ # cat /etc/rc.local
#! /bin/ash
export PATH=/sbin:/bin

log() {
   echo "$1"
   logger init "$1"
}

#execute all service retgistered in /etc/rc.local.d
if [http:// -d /etc/rc.local.d |http:// -d /etc/rc.local.d ]; then
   for filename in `find /etc/rc.local.d/ | sort`
      do
         if [ -f $filename ] && [ -x $filename ]; then
            log "running $filename"
            $filename
         fi
      done
fi

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 0 * * 1-5 /vmfs/volumes/simplejack-local-storage/ghettoVCB.sh -f /vmfs/volumes/simplejack-local-storage/backuplist > /vmfs/volumes/simplejack-local-storage/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
/bin/busybox crond

This will ensure that the cronjob is re-created upon a reboot of the system through a startup script

2. To ensure that this is saved in the ESXi configuration, we need to manually initiate an ESXi backup by running:

~ # /sbin/auto-backup.sh
config implicitly loaded
local.tgz
etc/vmware/vmkiscsid/vmkiscsid.db
etc/dropbear/dropbear_dss_host_key
etc/dropbear/dropbear_rsa_host_key
etc/opt/vmware/vpxa/vpxa.cfg
etc/opt/vmware/vpxa/dasConfig.xml
etc/sysconfig/network
etc/vmware/hostd/authorization.xml
etc/vmware/hostd/hostsvc.xml
etc/vmware/hostd/pools.xml
etc/vmware/hostd/vmAutoStart.xml
etc/vmware/hostd/vmInventory.xml
etc/vmware/hostd/proxy.xml
etc/vmware/ssl/rui.crt
etc/vmware/ssl/rui.key
etc/vmware/vmkiscsid/initiatorname.iscsi
etc/vmware/vmkiscsid/iscsid.conf
etc/vmware/vmware.lic
etc/vmware/config
etc/vmware/dvsdata.db
etc/vmware/esx.conf
etc/vmware/license.cfg
etc/vmware/locker.conf
etc/vmware/snmp.xml
etc/group
etc/hosts
etc/inetd.conf
etc/rc.local
etc/chkconfig.db
etc/ntp.conf
etc/passwd
etc/random-seed
etc/resolv.conf
etc/shadow
etc/sfcb/repository/root/interop/cim_indicationfilter.idx
etc/sfcb/repository/root/interop/cim_indicationhandlercimxml.idx
etc/sfcb/repository/root/interop/cim_listenerdestinationcimxml.idx
etc/sfcb/repository/root/interop/cim_indicationsubscription.idx
Binary files /etc/vmware/dvsdata.db and /tmp/auto-backup.31345.dir/etc/vmware/dvsdata.db differ
config implicitly loaded
Saving current state in /bootbank
Clock updated.
Time: 20:40:36   Date: 08/14/2009   UTC

Now you’re really done!

If you’re still having trouble getting the cronjob to work, ensure that  you’ve specified the correct parameters and there aren’t any typos in  any part of the syntax.

Ensure crond (cron daemon) is running:

ESX 3.x/4.0:

[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# ps -ef | grep crond | grep -v grep
root      2625     1  0 Aug13 ?        00:00:00 crond

ESXi 3.x/4.x/5.x:

~ # ps | grep crond | grep -v grep
5196 5196 busybox              crond

 

Ensure that the date/time on your ESX(i) host is setup correctly:

ESX(i):

[root@himalaya dlgCore-NFS-bigboi.VM-Backups]# date
Fri Aug 14 23:44:47 PDT 2009

 

Note: Careful attention must be noted if more than one backup is performed per day. Backup windows  should be staggered to avoid contention or saturation of resources  during these periods.

 


 

FAQ:

0Q: I’m getting error X when using the script or I’m not getting any errors, the backup didn’t even take place. What can I do?
0A: First off, before posting a comment/question, please thoroughly read through the ENTIRE documentation including the FAQs to see if your question has already been ansered.

1Q: I’ve read through the entire documentation + FAQs and still have not found my answer to the problem I’m seeing. What can I do?
1A: Please join the ghettoVCB Group to post your question/comment.

 

2Q: I’ve sent you private message or email but I haven’t received a response? What gives?
2A: I do not accept issues/bugs reported via PM or email, I will  reply back, directing you to post on the appropriate VMTN forum (that’s  what it’s for). If the data/results you’re providing is truely senstive  to your environment I will hear you out, but 99.99% it is not, so please  do not messsage/email me directly. I do monitor all forums that contain  my script including the normal VMTN forums and will try to get back to  your question as soon as I can and as time permits. Please do be patient as you’re not the only person using the script (600,000+ views), thank you.

3Q: Can I schedule backups to take place hourly, daily, monthly, yearly?
3A: Yes, do a search online for crontab.

4Q: I would like to setup cronjob for ESX(i) 3.5 or 4.0?
4A: Take a look at the Cronjob FAQ section in this document.

5Q: I want to schedule my backup on Windows, how do I do this?
5A: Do a search for plink. Make sure you have paired SSH keys setup between your Windows system and ESX/ESXi host.

6Q: I only have a single ESXi host. I want to take backups and  store them somewhere else. The problem is: I don’t have NFS, iSCSI nor  FC SAN. What can I do?
6A: You can use local storage to store your backups assuming that  you have enough space on the destination datastore.  Afterwards, you  can use scp (WinSCP/FastSCP) to transfer the backups from the ESXi host  to your local desktop.

7Q: I’m pissed; the backup is taking too long. My datastore is of type X?
7A: YMMV, take a look at your storage configuration and make sure it is optimized.

8Q: I noticed that the backup rotation is occurring after a  backup. I don’t have enough local storage space, can the process be  changed?
8A: This is primarily done to ensure that you have at least one  good backup in case the new backup fails. If you would like to modify  the script, you’re more than welcome to do so.

9Q: What is the best storage configuration for datastore type X?
9A: Search the VMTN forums; there are various configurations for the different type of storage/etc.

10Q: I want to setup an NFS server to run my backups. Which is the best and should it be virtual or physical?
10A: Please refer to answer 7A. From experience, we’ve seen  physical instances of NFS servers to be faster than their virtual  counterparts. As always, YMMV.

11Q: I have VMs that have snapshots. I want to back these things up but the script doesn’t let me do it. How do I fix that?
11A: VM snapshots are not meant to be kept for long durations.  When backing up a VM that contains a snapshot, you should ensure all snapshots have been committed prior to running a backup. No exceptions  will be made…ever.

12Q: I would like to restore from backup, what is the best method?
12A: The restore process will be unique for each environment and  should be determined by your backup/recovery plans. At a high level you have the option of mounting the backup datastore and registering the VM  in question or copy the VM from the backup datastore to the ESX/ESXi  host. The latter is recommended so that you’re not running a VM living  on the backup datastore or inadvertently modifying your backup VM(s). You can also take a look at ghettoVCB-restore which is experimentally supported.

13Q: When I try to run the script I get: “-bash: ./ghettoVCB.sh: Permission denied”, what is wrong?
13A: You need to change the permission on the script to be executable, chmod +x ghettoVCB.sh

14Q: Where can I download the latest version of the script?
14A: The latest version is available on on github – https://github.com/lamw/ghettoVCB/downloads

15Q: I would like to suggest/recommend feature X, can I get it?  When can I get it? Why isn’t it here, what gives?
15A: The general purpose of this script is to provide a backup  solution around VMware VMs. Any additional features outside of that  process will be taken into consideration depending on the amount of  time, number of requests and actual usefulness as a whole to the  community rather than to an individual.

16Q: I have found this script to be very useful and would like to contribute back, what can I do?
16A: To continue to develop and share new scripts and resources with the community, we need your support. You can donate here Thank You!

17Q: What are the different type of backup uses cases that are supported with ghettoVCB?
17A: 1) Live backup of VM with the use of a snapshot and 2)  Offline backup of a VM without a snapshot. These are the only two use  cases supported by the script.

18Q: When I execute the script on ESX(i) I get some funky errors such as “: not found.sh” or “command not found”. What is this?
18A: Most likely you have some ^M characters within the script  which may have come from either editing the script using Windows editor,  uploading the script using the datastore browser OR using wget. The  best option is to either using WinSCP on Windows to upload the script  and edit using vi editor on ESX(i) host OR Linux/UNIX scp to copy the  script into the host. If you still continue to have the issue, do a  search online on various methods of removing this Windows return  carriage from the script

19Q: My backup works fine OR it works for a single backup but I get an error message  “Input/output error” or “-ash: YYYY-MM-DD: not found” during the snapshot removal process. What is this?
19A: The issue has been recently identified by few users as a problem with user’s NFS server in which it reports an error when deleting large files that take longer than 10seconds. VMware has recently released a KB articlehttp://kb.vmware.com/kb/1035332 explaining the details and starting with vSphere 4.1 Update 2 or vSphere 5.0, a new advanced ESX(i) parameter has been introduced to increase the timeout. This has resolved the problem for several users and maybe something to consider if you are running into this issue, specifically with NFS based backups.

20Q: Will this script function with vCenter and DRS enabled?
20Q: No, if the ESX(i) hosts are in a DRS enabled cluster, VMs  that are to be backed up could potentially be backed up twice or never  get backed up. The script is executed on a per host basis and one would  need to come up a way of tracking backups on all hosts and perhaps write  out to external file to ensure that all VMs are backed up. The main use  case for this script are for standalone ESX(i) host

21Q: I’m trying to use WinSCP to manually copy VM files but it’s very slow or never completes on huge files, why is that?
21A: WinSCP was not designed for copying VM files out of your  ESX(i) host, take a look at Veeam’s FastSCP which is designed for moving  VM files and is a free utility.

22Q: Can I use setup NFS Server using Windows Services for UNIX (WSFU) and will it work?
22A: I’ve only heard a handful of users that have successfully  implemented WSFU and got it working, YMMV. VMware also has a KB article  decribing the setup process here: http://kb.vmware.com/kb/1004490 for those that are interested. Here is a thread on a user’s experience between Windows Vs. Linux NFS that maybe helpful.

23Q: How do VMware Snapshots work?
23A: http://kb.vmware.com/kb/1015180

24Q: What files make up a Virtual Machine?
24A: http://virtualisedreality.wordpress.com/2009/09/16/quick-reminder-of-what-files-make-up-a-virtual-machine/

25Q: I’m having some issues restoring a compressed VM backup?
25A: There is a limitation in the size of the VM for compression  under ESXi 3.x & 4.x, this limitation is in the unsupported Busybox  console and should not affect classic ESX 3.x/4.x. On ESXi 3.x,  the maximum largest supported VM is 4GB for compression and on ESXi 4.x  the largest supported VM is 8GB. If you try to compress a larger VM, you  may run into issues when trying to extract upon a restore. PLEASE TEST THE RESTORE PROCESS BEFORE MOVING TO PRODUCTION SYSTEMS!

26Q: I’m backing up my VM as “thin” format but I’m still not noticing any size reduction in the backup? What gives?
2bA: Please refer to this blog post which explains what’s going on: http://www.yellow-bricks.com/2009/07/31/storage-vmotion-and-moving-to-a-thin-provisioned-disk/

27Q: I’ve enabled VM_SNAPSHOT_MEMORY and when I restore my VM it’s still offline, I thought this would keep it’s memory state?
27A: VM_SNAPSHOT_MEMORY is only used to ensure when the  snapshot is taken, it’s memory contents are also captured. This is only  relavent to the actual snapshot itself and it’s not used in any  shape/way/form in regards to the backup. All backups taken whether your  VM is running or offline will result in an offline VM backup when you  restore. This was originally added for debugging purposes and in  generally should be left disabled

28Q: Can I rename the directories and the VMs after a VM has been backed up?
28A: The answer yes, you can … but you may run into all sorts  of issues which may break the backup process. The script expects a  certain layout and specific naming scheme for it to maintain the proper  rotation count. If you need to move or rename a VM, please take it out  of the directory and place it in another location

29Q: Can ghettoVCB support CBT (Change Block Tracking)?
29A: No, that is a functionality of the vSphere API + VDDK API (vSphere Disk Development Kit). You will need to look at paid solutions such as VMware vDR, Veeam Backup & Recovery, PHD Virtual Backups, etc. to leverage that functionailty.

 

30Q: Does ghettoVCB support rsync backups?
30A: Currently ghettoVCB does not support rsync backups, you either obtain or compile your own static rsync binary and run on ESXi, but this is an unsupported configuration. You may take a look at this blog post for some details.

 

31Q: How can I contribute back?

31A: You can provide feedback/comments on the ghettoVCB Group. If you have found this script to be useful and would like to contribute back, please click here to donate.

 

32Q: How can select individual VMDKs to backup from a VM?

32A: Ideally you would use the “-c” option which requires you to create individual VM configuration file, this is where you would select specific VMDKs to backup. Note, that if you do not need to define all properties, anything not defined will adhere from the default global properties whether you’re editing the ghettoVCB.sh script or using ghettoVCB global configuration file. It is not recommended that you edit the ghettoVCB.sh script and modify the VMDK_FILES_TO_BACKUPvariable, but if you would like to keep everything in one script, you may add the extensive list of VMDKs to backup but do know this can get error prone as script may be edited frequently and lose some flexibility to support multiple environments.

 

33Q: Why is email not working when I’m using ESXi 5.x but it worked in ESXi 4.x?

33A: ESXi 5.x has implemented a new firewall which requires the email port that is being used to be opened. Please refer to the following articles on creating a custom firewall rule for email:

http://www.virtuallyghetto.com/2012/09/creating-custom-vibs-for-esxi-50-51.html

How to Create Custom Firewall Rules in ESXi 50

How to Persist Configuration Changes in ESXi 4.x/5.x Part 1

How to Persist Configuration Changes in ESXi 4.x/5.x Part 2

 

34Q: How do I stop the ghettoVCB process?

34A: Take a look at the Stopping ghettoVCB Process section of the documentation for more details.

 


 

Our NFS Server Configuration

Many have asked what is the best configuration and recommendation for  setting up a cheap NFS Server to run backups for VMs. This has been a  question we’ve tried to stay away from just because the possiblities and  solutions are endless. One can go with physical vs. virtual, use VSA  (Virtual Storage Appliances) such as OpenFiler or Lefthand Networks,  Windows vs. Linux/UNIX. We’ve not personally tested and verify all these  solutions and it all comes down to “it depends” type of answer. Though  from our experience, we’ve had much better success with a physical  server than a virtual.

It is also well known that some users are experiencing backup issues  when running specifically against NFS, primarily around the rotation and  purging of previous backups. The theory from what we can tell by  talking to various users is that when the rotation is occuring, the  request to delete the file(s) may take awhile and does not return within  a certain time frame and causes the script to error out with unexpected  messages. Though the backups were successful, it will cause unexpected  results with directory structures on the NFS target. We’ve not been able  to isolate why this is occuring and maybe due to NFS  configuration/exports or hardware or connection not being able to  support this process.

We’ll continue to help where we can in diagonising this issus but we  wanted to share our current NFS configuration, perhaps it may help some  users who are new or trying to setup their system. ( Disclaimer: These configurations are not recommendations nor endorsement for any of the components being used)

UPDATE: Please also read FAQ #19 for details + resolution

Server Type: Physical
Model: HP DL320 G2
OS: Arch linux 2.6.28
Disks: 2 x 1.5TB
RAID: Software RAID1
Source Host Backups: ESX 3.5u4 and ESX 4.0u1 (We don’t run any ESXi hosts)

uname -a output

Linux XXXXX.XXXXX.ucsb.edu 2.6.28-ARCH #1 SMP PREEMPT Sun Jan 18 20:17:17 UTC 2009 i686 Intel(R) Pentium(R) 4 CPU 3.06GHz GenuineIntel GNU/Linux

NICs:

00:05.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02)
00:06.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02)

NFS Export Options:

/exports/vm-backups XXX.XXX.XXX.XXX/24(rw,async,all_squash,anonuid=99,anongid=99)

 

*One important thing to check is to verify that your NFS exportion options are setup correctly, “async” should be configured to ensure that all IO requests are processed and  reply back to the client before waiting for the data to be written to  the storage.

*Recently VMware released a KB article describing the various “Advanced NFS Options” and their meanings and recommendations: http://kb.vmware.com/kb/1007909 We’ve not personally had to touch any of these, but for other vendors  such as EMC and NetApp, there are some best practices around configuring  some of these values depending on the number of NFS volumes or number  of ESX(i) host connecting to a volume. You may want to take a look to  see if any of these options may help with NFS issue that some are seeing

*Users should also try to look at their ESX(i) host logs during the time  interval when they’re noticing these issues and see if they can find  any correlation along with monitoring the performance on their NFS  Server.

*Lastly, there are probably other things that can be done to improve NFS  performance or further optimization, a simple search online will also  yield many resources.


 

Useful Links:

Windows utility to email ghettoVCB Backup Logs – http://www.waldrondigital.com/2010/05/11/ghettovcb-e-mail-rotate-logs-batch-file-for-vmware/
Windows front-end utility to ghettoVCB –  http://www.magikmon.com/mkbackup/ghettovcb.en.html

Note: Neither of these tools are supported, for questions or comments regarding these utilities please refer to the author’s pages.

 


 

Change log:

01/13/13 –

 

Enhancements:

  • ghettoVCB & ghettoVCB-restore supports ESXi 5.1
  • Support for individual VM backup via command-line and added new -m flag
  • Support VM(s) with existing snapshots and added new configuration variable calledALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP
  • Support multiple running instances of ghettoVCB running and added a new -w flag
  • Configure VM shutdown/startup order and added two new configuration variables called VM_SHUTDOWN_ORDERand VM_STARTUP_ORDER
  • Support changing custom VM name during restore
  • Documentation updates

Fixes:

  • Fixed tab/indentation for both ghettoVCB/ghettoVCB-restore
  • Temp email files and email headers
  • Fixed “whoami” command as it is no longer valid in ESXi 5.1 to check for proper user
  • Added 2gbsparse check in sanity method to auto-load VMkernel module
  • Various typos, for greater detail, you can refer to the “diff” in github repo

 

—————————————————————————————————————————————————————————————————————————

11/19/11 –

 

Enhancements:

  • ghettoVCB & ghettoVCB-restore is now packaged together and both scripts are versioned on github
  • ESXi 5 firewall check for email port (Check FAQ #33 for more details)
  • New EMAIL_DELAY_INTERVAL netcat variable to control slow SMTP servers
  • ADAPTER_TYPE (buslogic,lsilogic,ide) no longer need to manually specified, script will auto-detect based on VMDK descriptor file
  • Using symlink -f parameter for quicker unlink/re-link for RSYNC use case
  • Updated documentation, including NFS issues (Check FAQ #19 for more details including new VMware KB article)

Fixes:

  • vSphere 4.1 Update 2 introduced new vim-cmd snapshot.remove param, this has now been updated in script to detect this new param change

 

—————————————————————————————————————————————————————————————————————————

06/28/11 –

Enhancements:

  • Support for vSphere 5.0 – ESXi 5.0

 

—————————————————————————————————————————————————————————————————————————

05/22/11 –

Enhancements:

 

  • Support for multiple email recipients
  • Support for individual VMDK backup within ghettoVCB.sh script – FAQ #33

 

Fixes:

  • Minor fix in additional validation prior to VM rotation

 


03/14/11 –

 

Enhancements:

  • Enhanced “dryrun” details including configuration and/or VMDK(s) issues
    • Warning messages about physical RDM and Independent VMDK(s)
    • Warning messages about VMs with snapshots
  • New storage debugging details
    • Datastore details both pre and post backups
    • Datstore blocksize miss-match warnings
  • Quick email status summary is now included in the title of the email, this allows a user to quickly verify whether a backup was successful or had complete/partial failure without having to go through the logs.
  • Updated ghettoVCB documentation
  • ghettoVCB going forward will now be version tracked via github and previous releases will not be available for download

Fixes:

  • Updated absolute sym link path for RSYNC_LINK variable to relative path
  • Enhanced logging and details on warning/error messages

 

Big thanks to Alain Spineux and his contributions to the ghettoVCB script and helping with debugging and testing.

 


09/28/10 –

Enhancements:

 

  • Additional email support for Microsoft IIS and email debugging functionality (Experimental Support)
  • ghettoVCB PID is now captured in the logs
  • Rsync support, please take a look at the above documentation for Rsync Support (Experimental Support)

Fixes:

 

  • Fixed a few typos in the script
  • Trapping SIG 13

 

 


 

07/27/10 –

Enhancements:

 

  • Support for emailing backup logs (Experimental Support)

 

 


 

07/20/10 –

Enhancements:

 

  • Support for vSphere 4.1 (ESX and ESXi)
  • Additional logging information for debugging purposes

 

 


 

05/12/10 –

Enhancements:

 

  • Thanks to user Rodder who submitted a patch for a workaround  to handle the NFS I/O issue. The script will check to see if the return  code of the “rm” operation for VMs that are to be rotated. If the return  code has not returned right away, we may be running into the NFS I/O  issue, the script will not sleep and check perodically to see if NFS  volume is responsive and then continue to the next VM for backup.

Fixes:

 

  • Resolved the problem when trying to specify ghettoVCB global configuration file with the fullpath

 

 


 

05/11/10 –

 

 

  • Updated useful links to 2 utilties that were written by users for ghettoVCB

 

 


 

05/05/10 –

Fixes:

 

  • Resolved an issue where VMs with spaces were not being properly rotated. Thanks to user chrb for finding the bug

 

 


 

04/24/10 –

Enhancements:

 

  • Added the ability to include an exclusion list of VMs to not backup

Fixes:

 

  • Resolved persistent NFS configuration bug due to the addition of the global ghettoVCB conf

 

 


 

04/23/10 –

Fixes:

 

  • Resolved a bug in the VM naming directory which may not delete backups properly

 

 


 

04/20/10 –

 

 

  • Support for global ghettoVCB configuration file. Users no longer  need to edit main script and can use multiple configuration files based  on certain environment configurations
  • Ability to backup all VMs residing on a specific host w/o specifying VM list
  • Implemented simple locking mechenism to ensure only 1 instance of ghettoVCB is running per host
  • Updated backup directory structure – rsync friendly. All backup VM  directories will now have the format of “VMNAME-YYYY-MM-DD_HH_MM_SS”  which will not change once the backup has been completed. The script  will keep N-copies and purge older backups based on the configurations  set by the user.
  • Additional logging and final status output has been added to the  script to provide more useful error/warning messages and an additoinal  status will be printed out at the end of each backup to provide an  overall report

Big thanks goes out to the community for the suggested features and to those that submitted snippet of their modifications.


 

03/27/10 –

 

  • Updated FAQ #0-1 & #25-29 for common issues/questions.
  • For those experiencing NFS issue, please take a look at FAQ #29
  • Re-packaged ghettoVCB.sh script within a tarball (ghettoVCB.tar.gz)  to help assist those users having the “Windows affect” when trying to  execute the script

 


 

02/13/10 –

Updated FAQ #20-24 for common issues/questions.      Also included a new section about our “personal” NFS configuration and setup.


 

01/31/10 –

Fix the crontab section to reflect the correct syntax + updated FAQ #17,#18 and #19 for common issues.


 

11/17/09 –

The following enhancements and fixes have been implemented in this  release of ghettoVCB. Special thanks goes out to all the ghettoVCB BETA  testers for providing time and their environments to test features/fixes  of the new script!

Enhancements:

 

  • Individual VM backup policy
  • Include/exclude specific VMDK(s)
  • Logging to file
  • Timeout variables
  • Configur snapshot memory/quiesce
  • Adapter format
  • Additional logging + dryrun mode
  • Support for both physical/virtual RDMs

Fixes:

  • Independent disk awareE

LuManager开启探针读取内存等数据

前两天,有网友遇到同样的问题,现在解决了,特记录下来,让后来者参考。

因为跨目录访问了,需要设置一个cgi端口,这个端口在 左上角 网站(虚拟主机) –> FastCGI端口 ( 请填写9000-20000之间的数字 )那里设置,只有商业授权版才有。

LUM后台 –> 配置与优化 –> 修改配置文件

/usr/local/php_fcgi/lib/php.ini: FastCGI模式的PHP配置文件

open_basedir = "/proc:/home:/tmp:/var/tmp"

在LUM 2.0.68版测试通过。

多谢洞哥的指导,谢谢。

解决无法访问windows installer服务

在 Windows XP 中安装程序时出现“The Windows Installer Service Could Not Be Accessed”(无法访问 Windows Installer 服务)错误消息
要解决此问题,请按照下列步骤操作:
方法一:
卸载,重新安装windows installer服务
一、先用dos命令窗口msiexec /unregserver 停掉windows installer服务。
二、下载InstMsiW.exe,用winrar解压开。进入目录。

下载: INSTMSIW.EXE

三、右击msi.inf ,点击安装,右击mspatcha.inf ,点击安装。
四、再用dos命令窗口msiexec.exe /regserver 启用服务。
方法二:
1.如果曾安装过ACDSee5.0(包括迷你中文版),卸载它。如果还不行就重装Windows
Installer 或者ACDSee 4.0

下载: WindowsInstaller-KB893803-v2-x86.exe

2.运行cmd,然后运行sfc/scannow检查系统文件
3.运行Services.msc,把Windows Installer 服务设置为手动运行,然后重新运行
4.打开任务管理器,找到并结束ikernel.exe进程,重新安装
5.禁用杀毒软件的实时防护
6.删除 C:\Program Files\Common Files\InstallShield\Engine\6\Intel 32这个文
件夹中的所有文件,然后重启动电脑,重新运行安装程序
方法三:
这是由于一些软件制作的问题导致windows installer不能正常工作
恢复步骤如下:
1.再次安装windows installer2.0,运行instmsiw.exe
如果说”服务已经安装”然后直接退出安装就再跟着做,否则你重装就OK了!
2.删除注册表中的[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSIServer]
然后运行instmsiw.exe
3.绝招:
(1) 删除msiserver 服务
运行regedit,删除下面的MSIServer 服务
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSIServer]
把下面的内容存为unmsiserver.reg 文件,然后双击左键,把它合并进注册表中

    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;unmsiserver.reg
    Windows Registry Editor Version 5.00
    [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSIServer]
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  

(2) 删除msi 的文件
用下面的脚本存为一个unmsi.inf文件,然后在inf文件上右键单击install,就会删除一些msi的dll,这时windows 的 sfc机制可能警告一些系统文件被修改要求插入win2k的光盘,不理睬它。这个脚本是我从instmsiw.exe中修改得来的。

    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;unmsi.inf
    ;;;;;;;;;;;;;;;;;
    [Version]
    signature = "$Windows NT$"
    Class = %ExceptionClassDesc%
    ClassGUID = {F5776D81-AE53-4935-8E84-B0B283D8BCEF}
    Provider = %Microsoft%
    CatalogFile = msi.cat
    ComponentId = {2E742517-5D48-4DBD-BF93-48FDCF36E634} ; GUID assigned to the Windows Installer
    DriverVer=03-13-2001, 2.0.2460.1
    [SourceDisksNames]
    1 = %msi_media%
    [SourceDisksFiles]
    msi.dll = 1
    msihnd.dll = 1
    msimsg.dll = 1
    msiexec.exe = 1
    msisip.dll = 1
    [DestinationDirs]
    Msi.SystemFiles = 11 ; %windir%\system32
    Msi.DllCacheFiles = 11,dllcache ; %windir%\system32\dllcache
    [DefaultInstall]
    DelFiles = Msi.SystemFiles,Msi.DllCacheFiles
    ;
    ; COPYFLG_REPLACE_BOOT_FILE flag (0x1000) not necessary for
    ; files in the dllcache
    ;
    [Msi.DllCacheFiles]
    msi.dll
    msihnd.dll
    msimsg.dll
    msiexec.exe
    msisip.dll
    [Msi.SystemFiles]
    msi.dll
    msihnd.dll
    msimsg.dll
    msiexec.exe
    msisip.dll
    [Strings]
    Microsoft = "Microsoft Corporation"
    msi_media = "Microsoft Windows Installer Distribution Media"
    ExceptionClassDesc = "Microsoft Windows Installer"
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  

(3) 重新启动,按F8键,进入带命令行的安全模式,执行下面的命令

    regsvr32 /u %windir%\msi.dll
    del %windir%\msi.dll
  

(4) 重启动,运行instmsiw.exe,安装windows installer ,一切正常了。
以管理员身份登录到计算机。
单击“开始”,然后单击“运行”。
在“打开”框中,键入 cmd,然后单击“确定”。
在命令提示符下,键入 msiexec.exe /unregister,然后按 Enter。
键入 msiexec /regserver,然后按 Enter。
验证 SYSTEM 帐户对 Windows 注册表中的 HKEY_CLASSES_ROOT 配置单元具有完全控制访问权限。在某些情况下,也可能需要添加管理员帐户。为此,请按照下列步骤操作:警告:如果使用注册表编辑器或其他方法错误地修改了注册表,则可能导致严重问题。这些问题可能需要重新安装操作系统才能解决。Microsoft 不能保证您可以解决这些问题。修改注册表需要您自担风险。
单击“开始”,单击“运行”,在“打开”框中键入 regedit,然后单击“确定”。
单击以下注册表配置单元:
HKEY_CLASSES_ROOT
在“编辑”菜单上,单击“权限”。
如果“SYSTEM”没有在“组或用户名”列表中列出,请单击“添加”,确保本地计算机名称出现在“查找位置”框中,在“输入对象名称来选择”框中键入 system,单击“检查名称”,然后单击“确定”。
在“组或用户名”列表中单击“SYSTEM”,然后选中“SYSTEM 权限”框中“允许”下的“完全控制”复选框。
单击“应用”,然后单击“确定”退出注册表编辑器。
重新启动计算机。

怎样让中文XP变为英文系统的界面

微软是不提供xp英文语言包下载的。有三种方法,可将中文xp转换为英文。推荐使用方法一和方法三。
方法一:
直接安装英文版xp。如想再换成中文,下载中文语言包即可。
方法二:
将系统盘中以下文件   
  C:\WINDOWS\system32\mydocs.dll   
  C:\WINDOWS\Explorer.exe   
  C:\WINDOWS\system32\shell32.dll   
  C:\WINDOWS\system32\browselc.dll   
  C:\WINDOWS\system32\logonui.exe   
  覆盖为   
  英文版的explorer.exe   
  英文版的shell32.dll   
  英文版的logonui.exe   
  英文版的browselc.dll   
  英文版的mydocs.dll   
  就搞定了……   
  注意:可将系统中大部分都变英文了,但是有些是没有没法变的。此外,由于系统盘中的文件被保护,会遇到不能将文件覆盖的问题,在DOS中进行操作,可解决不能将系统盘中的文件覆盖的问题。
方法三:
如果你已经装了中文的sp3的补丁,就把它卸载了吧,方法这里不再赘述。
  第一步:从语言的本源入手。打开注册表,找到hkey_local_machine\system\controlset001\control\nls\language,把“default”和“installlanguage”的的值“0804”改为“0409” (见图)。“0804”是简体中文的语言代号,“0409”是英文的语言代号。
  小提示
  如果之前下载的是sp3的其他语言补丁,如法语(代码为040c)、西班牙语、日语、俄语等,安装后在这一步中更换为相应代号即可。
  第二步:打开控制面板系统语言设置,将位置等换成英语(美国)。这两步必须进行,否则不能安装英文版的sp3补丁。重启后就可以安装英文sp3补丁了,补丁全称是windowsxp-kb936929-sp3-x86-enu.exe,你可以到微软的官方网站下载: http://www.microsoft.com/downloads/details.aspx?FamilyId=5B33B5A8-5E76-401F-BE08-1E1555D4F3D4&displaylang=en

word-wrap break-word使文本自动换行

在内容属性那里加上word-wrap: break-word;
如果右边留白太多的话,可以用word-break : break-all;

《使用word-wrap:break-word使文本自动换行》

文本框连续输入
数字”111111111111111111″或者
英文单词”adkjsakfjsalfkjsalkdjaslkfjsalkf”
会造成什么结果呢?—文字溢出,一般的处理方法是用overflow:hidden隐藏文字,有没有更好的解决文案呢?QA的童鞋要求自动换行.

用word-wrap:break-word即可

css手册上的解释
word-wrap
基本特性
兼容性: IE5.5+专有属性
基本语法
word-wrap : normal | break-word
语法取值
normal: 默认值。允许内容顶开指定的容器边界
break-word:内容将在边界内换行。如果需要,词内换行( word-break )也将发生
使用说明
设置或检索当当前行超过指定容器的边界时是否断开转行。此属性仅作用于有布局的对象,如块对象。内联要素要使用该属性,必须先设定对象的 height 或 width 属性,或者设定 position 属性为 absolute ,或者设定 display 属性为 block 。此属性对于 currentStyle 对象而言是只读的。对于其他对象而言是可读写的。对应的脚本特性为 wordWrap 。

w3c的解释

http://www.w3.org/TR/css3-text/#word-wrap

转自http://www.putaoshu.com/?p=359

《word wrap 解惑》

源起
我们经常需要“修复”一个老生常谈的“bug”,那就是文本的自动换行问题。在专业术语上,这种期望得到的渲染现象被称作“word wrap”,即文本处理器有能力把超出页边的整个词自动传到下一行。

在现实项目中,尤其是在测试阶段,鉴于测试使用非常极端的测试用例,我们经常需要“修复”如图所示的这个问题:

word-wrap-1

长单词溢出

图中,极长的这个英文单词(虽然是生造的)为了保证完整的显示,无奈地超出了容器的限制,它溢出了。为了“修复”这个“问题”,使得无论东亚还是西欧文字都能被限定在容器的尺寸范围内,我们一般会加上诸如“word-wrap: break-word; word-break: break-all;”这样的属性,令我们满意(好吧,其实是令测试满意)的结果如图所示:

word-wrap-2

长单词被强行断行

从以结果现象为导向的观点出发,这个“bug”被“修复”了,但是在做了三五次这样的重复工作后,我开始产生这样几个疑问:

word-wrap 和 word-break 究竟是什么?
为什么会乐此不疲地重复碰到这个问题?
这个问题是问题么?
规则
在解惑之前,有几个关乎问题本质的客观现实需要指出,因为这些“常识”最容易被人忽视:

CJK 文字和 !CJK 文字有各自的排版规则。

在这里,CJK 代表 Chinese, Japanese, and Korean,即东亚文字,!CJK 就是非东亚文字,大多数情况下是西欧文字。

在文字的呈现规则上,两者很不相同,CJK 文字中,一个字母就是一个字素(单词),独立成义,!CJK 文字中,一些字母组成一个字素,并且字素们由连接符“-”连接,或由空格“ ”分隔。

有关 CJK 文字更多的排版规则上,比较有代表性的是:对中文来说,标点符号不能成为行首(特殊除外);双字长的标点符号(省略号、破折号)不能断开。
对于 !CJK,主要是:单词不能在中间不合法地断开(合法情况例如从连接符处断开);标点符号不能成为行首(特殊除外)
解惑一
word-wrap 和 word-break 究竟是什么?对于这个问题,直接拜访 W3C 官方,找到 CSS3 草案:http://www.w3.org/TR/2010/WD-css3-text-20101005/,再访问微软,借鉴诸如 http://msdn.microsoft.com/en-us/library/ms531184%28VS.85%29.aspx

得出的结论如下:

word-wrap, line-break, word-break 这几个属性都是 MS 的独立实现,随后其他浏览器也不同程度地实现了其中的某些,之后,这几个属性都被吸纳为 CSS3 标准。在对文字排版的渲染上,微软还是走在前面的。

在现有的 CSS3 草案中,关乎到文字排版的几个重要属性有:white-space, text-wrap, word-wrap, line-break, word-break

根据 CSS3 的描述,列出这些属性各自的要点,这部分读者可以跳过……

white-space 是 white-space-collapsing 和 text-wrap 的缩写
属性 设置 white-space-collapsing 设置 text-wrap 空行 空格 文字自动换行 效果
normal collapse normal collapse collapse wrap 忽略多余空行和空格,文字自动换行
pre preserve none preserve preserve no wrap 保留所有空行和空白,文字不自动换行
nowrap collapse none collapse collapse no wrap 忽略多余空行和空格,文字不自动换行
pre-wrap preserve normal preserve preserve wrap 保留所有空行和空白,文字自动换行
pre-line preserve-breaks normal preserve collapse wrap 合并多余空格,保留多余空行,文字自动换行
text-wrap 定义文本的自动换行效果
属性 效果
normal 在允许的断点处自动换行
none 文本不会自动换行;对于不“合身”的容器,文本将会溢出
unrestricted 在任意的文法单词间都可断行,比 normal 的限制要松散很多
suppress 除非断行处没有其他任何允许的断点,方可进行断行,这比 unrestricted 严格,比 normal 松散
word-wrap 执行最激进的单词断行控制,从单词的内部断开以防止文本溢出容器并且完全适应容器的宽度
在 IE 的实际效果中,word-break 的效果要激进得多,它穷凶极恶地断开所有单词(如果到达边界的话)
属性 效果
normal 仅在允许的文本断点处自动换行
break-word 如果一行中没有其他可接受的断点,那么将强行断开文本单词
line-break 是断行的规则,针对东亚文字
基本是针对日文的换行规则
word-break 是断行的规则,针对非东亚文字
属性 效果
normal 根据特定非东亚文字自己的规则来决定是否自动断行
break-all 允许非东亚语言文本行的任意字内断开。该值适合包含一些非东亚文本的东亚文本
keep-all 不允许非东亚语言文本行的任意字内断开。该值适合包含一些东亚文本的非东亚文本
hyphenation 文本会在合适的连字符处断开,这需要浏览器的支持
做一个归纳:专门用于控制文本自动换行功能的属性是 text-wrap 和 word-wrap,而 line-break 和 word-break 用来控制断行和单词边界分隔,根据 W3C 的描述来说,word-wrap 是最激进的自动换行方式,可以强行断开单词。而现实情况是,word-break: break-all; 的方式要更为激进,如图:

word-wrap-3

word-wrap

word-wrap-4

word-break

对比 word-wrap: break-word; 和 word-break: break-all;,两者都将文本限定在了容器的范围内,只是 break-all 将所有单词,不论长短地,通通截断,break-word 则非如此,它尽量地遵从了排版规则。

兼容性
由于几个属性都来自于微软(部分来自于 CSS3),那么理所当然 IE 是支持最良好的,不过对于浮动元素,IE67 的表现会有些 bug(可在文后给出的 demo 中验证)。

至于其他浏览器,FF 3.6 不支持 word-break;Chrome 7 支持良好;Safari 5 同 Chrome;Opera 10 同 FF

解惑二三
碰到相关问题的场景大体是两个:

测试使用了很极端的测试用例(比如 asdfasdfasdfasdfasdfasdfasdf)
IE67 下,在宽度不大的容器中使用了浮动元素,同时浮动元素内包含了长的串,如图:

word-wrap-5

IE67 中浮动盒子杯具

对于场景一,使用 word-wrap: break-word;

对于场景二,使用 IE67 的 hack,word-break: keep-all; 或者用 inline-block 来代替浮动(IE67 中,hasLayout 的 inline 盒子大体等同于 inline-block)

回头看疑问二,我们为什么会乐此不疲地重复碰到这个问题?原则上,各个浏览器默认的文字排版方式已经很好地顾及了 CJK 文字和 !CJK 文字,根据各个语言自己的规则来呈现排版,不应该出现诡异的问题。所以,对于上面的两个问题场景,之所以产生场景一,是因为使用了极端的测试用例,但是在现实中,这种极长的英文单词是根本不存在的(特殊行业除外),又,即使英文单词较长,也不应该突兀地截断,这有违西欧文字的排版规则。所以我认为,如果在现实环境下发生场景一中的问题,责任应该在于版面的设计,比如容器宽度太小,而不是去截断文本;对于场景二,应该归咎于 IE67 的渲染 bug,这时,使用 inline-block 代替,或用 word-break: keep-all; 来给犯错的浏览器擦屁股。

实践方案
对于我们输出的内容(可控的),不使用任何 word-wrap 和 word-break 等属性,对于可能产生的长单词溢出这种小概率事件,首先考虑容器宽度是否合理,其次可以为长单词添加连字符“-”以便合理地断开,最后设置 overflow: hidden; 避免视觉上的溢出。
对于用户输出的内容(不可控的),比如评论等,由于不排除用户会输入“dddddddddddd”这样没营养的垃圾数据,使用 word-wrap: break-word; 来强行截断。
最后的观点
不能完全迁就测试用例,因为有时不合现实情理。
浏览器默认已经做得够好,强加诸如 break-all; 这样的指令是不优雅的。
问题大多不在于实现,而在于设计(如容器太窄)。
对于 bug 浏览器使用 hack 即可,这是它们的错。
相关资源
CSS3 草案:http://www.w3.org/TR/2010/WD-css3-text-20101005/
demo 页面:http://ued.taobao.com/lab/word-wrap/word-wrap.html

转自http://ued.taobao.com/blog/2010/10/14/research-of-word-wrap/

提示“Microsoft Office Word 遇到问题需要关闭”的解决脚本

以下代码保存为bat批处理文件运行即可。

@echo off 
color 07
@ ECHO -------------------------------------------------------------------------------- 
@ ECHO 打开WORD文档出错提示: 
@ ECHO Microsoft Office Word 遇到问题需要关闭。我们对此引起的不便表示抱歉。 
@ ECHO 您正在处理的信息有可能丢失。Microsoft Office Word 可以尝试为您恢复。 
@ ECHO -------------------------------------------------------------------------------- 
@ ECHO 系统询问是否需要发送错误报告,不论选择哪一个,循环重启Word,重复出 
@ ECHO 现相同警告对话框。之后出现“安全模式启动WORD”,确定出现WORD空白页。 
@ ECHO -------------------------------------------------------------------------------- 
echo   ◆ 
echo   本BAT处理将尝试为你修复以上问题。 
echo   ◆ 
@ ECHO -------------------------------------------------------------------------------- 
echo   注意:请先关闭所有Word文档程序,按任意键开始修复...... 
@ ECHO -------------------------------------------------------------------------------- 
pause>nul 
del /f /s /q "%userprofile%\local settings\temp\*.*" 
del /f /s /q "%appdata%\microsoft\Templates\*.dot" 
del /f /s /q "%appdata%\microsoft\Word\Startup\*.dot"
start winword 
color 07 
@ ECHO -------------------------------------------------------------------------------- 
@ ECHO BAT程序执行完毕,请按任意键退出... 
@ ECHO -------------------------------------------------------------------------------- 
pause>nul