C1G军火库

linux备份真是太方便了，其实我们常用的tar就是很好的增量备份软件

使用 tar -g 参数进行增量备份实验

完整备份:

#建立测试路径与档案
mkdir test
touch test/{a,b,c};
在test下生成三个文件

#执行完整备份
tar -g snapshot -zcf backup_full.tar.gz test

#查看 tarball 内容
tar ztf backup_full.tar.gz
test/
test/a
test/b
test/c

增量备份:

#新增一个档案
touch test/d

#执行第一次的增量备份 (注意 tarball 档名)
tar -g snapshot -zcf backup_incremental_1.tar.gz test

#查看 tarball 内容
tar ztf backup_incremental_1.tar.gz
test/
test/d

#新增一个档案, 并异动一个档案内容
touch test/e
echo 123 > test/a

#执行第二次的增量备份 (注意 tarball 档名)
tar -g snapshot -zcf backup_incremental_2.tar.gz test

#查看 tarball 内容
tar ztf backup_incremental_2.tar.gz
test/
test/a
test/e

还原备份资料:

#清空测试资料
rm -rf test

#开始进行资料还原
tar zxf backup_full.tar.gz
tar zxf backup_incremental_1.tar.gz
tar zxf backup_incremental_2.tar.gz

#查看测试资料
ls test
a b c d e

使用 tar -u 参数进行增量备份

第一次备份:

#建立测试路径与档案
mkdir test
touch test/a test/b test/c

#备份资料
tar zcf backup.tar.gz test

#查看 tarball 内容
tar ztf backup.tar.gz
test/
test/a
test/b
test/c

增量备份:

#新增一个档案, 并异动一个档案内容
touch test/d
echo 123 > test/a

#执行增量备份 (-u 参数只能执行於未压缩的 tarball)
gunzip backup.tar.gz
tar uf backup.tar test
gzip backup.tar

#查看 tarball 内容
tar ztf backup.tar.gz
test/
test/a
test/b
test/c
test/
test/a
test/d

还原备份资料:

#清除测试资料
rm -rf test

#解包 tarball
tar zxf backup.tar.gz

#查看测试资料
ls test
a b c d

以下内容存成chkdesk.sh

<coolcode>

#!/bin/bash  DISKUSAGE=$(df -h |awk -F " " '{print $5}'|sort -n -r|sed -n '1s/[^0-9]//p') DIR=$(df -h |awk -F " " '{print $5,$1}' |sort -nr|awk -F " " 'NR==1 {print $2}') NUM=80 (定义的磁盘非分比)

function Send_Mail { (sleep 2;echo "helo localhost" sleep 1;echo "auth login" sleep 1;echo "YW5keQ==" （base64后的用户名） sleep 1;echo "MTIzNDU2"  (base64后的密码) sleep 1;echo "mail from:<service@c1gstudio.com>" sleep 1;echo "rcpt to:<admin@domain.com>" sleep 1;echo "data" sleep 1;echo "From:"disk" <service@c1gstudio.com>" sleep 1;echo "to:"admin" <admin@domain.com>" sleep 1;echo "Subject:your web01 disk directory $DIR is full" sleep 1;echo "Content-Type:text/plain;" sleep 1;echo "Content:" sleep 1;echo "web01 disk  directory $DIR is full" sleep 1;echo "." sleep 1;echo "quit")| telnet 192.168.1.1 25 >/dev/null 2>&1 }  if [ $DISKUSAGE -ge $NUM ] ; thengmail         Send_Mail         echo "already suuess send alert message" fi

</coolcode>

#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

LAST_ACK 14
SYN_RECV 348
ESTABLISHED 70
FIN_WAIT1 229
FIN_WAIT2 30
CLOSING 33
TIME_WAIT 18122

状态：描述
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放
LAST_ACK：等待所有分组死掉

也就是说，这条命令可以把当前系统的网络连接状态分类汇总。

下面解释一下为啥要这样写：

一个简单的管道符连接了netstat和awk命令。

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

先来看看netstat：

netstat -n

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 123.123.123.123:80 234.234.234.234:12345 TIME_WAIT

你实际执行这条命令的时候，可能会得到成千上万条类似上面的记录，不过我们就拿其中的一条就足够了。

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

再来看看awk：

/^tcp/
滤出tcp开头的记录，屏蔽udp, socket等无关记录。

state[]
相当于定义了一个名叫state的数组

NF
表示记录的字段数，如上所示的记录，NF等于6

$NF
表示某个字段的值，如上所示的记录，$NF也就是$6，表示第6个字段的值，也就是TIME_WAIT

state[$NF]
表示数组元素的值，如上所示的记录，就是state[TIME_WAIT]状态的连接数

++state[$NF]
表示把某个数加一，如上所示的记录，就是把state[TIME_WAIT]状态的连接数加一

END
表示在最后阶段要执行的命令

for(key in state)
遍历数组

print key,”\t”,state[key]
打印数组的键和值，中间用\t制表符分割，美化一下。

如发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决，
vim /etc/sysctl.conf
编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后执行 /sbin/sysctl -p 让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间

下面附上TIME_WAIT状态的意义：

客户端与服务器端建立TCP/IP连接后关闭SOCKET后，服务器端连接的端口
状态为TIME_WAIT

是不是所有执行主动关闭的socket都会进入TIME_WAIT状态呢？
有没有什么情况使主动关闭的socket直接进入CLOSED状态呢？

主动关闭的一方在发送最后一个 ack 后
就会进入 TIME_WAIT 状态 停留2MSL（max segment lifetime）时间
这个是TCP/IP必不可少的，也就是“解决”不了的。

也就是TCP/IP设计者本来是这么设计的
主要有两个原因
1。防止上一次连接中的包，迷路后重新出现，影响新连接
（经过2MSL，上一次连接中所有的重复包都会消失）
2。可靠的关闭TCP连接
在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发
fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以
主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。

TIME_WAIT 并不会占用很大资源的，除非受到攻击。

还有，如果一方 send 或 recv 超时，就会直接进入 CLOSED 状态

mysql+ftp备份

http://blog.c1gstudio.com/archives/13

自动ssh/scp方法配置
A为本地主机(即用于控制其他主机的机器) ;
B为远程主机(即被控制的机器Server), 假如ip为192.168.60.110;
A和B的系统都是Linux

在A上运行命令:

#cd ~
# ssh-keygen -t rsa (连续三次回车,即在本地生成了公钥和私钥,不设置密码)
# ssh backup@192.168.60.110“mkdir .ssh” (建立目录，需要输入密码，只需一次)
# scp ~/.ssh/id_rsa.pub backup@192.168.60.110:.ssh/id_rsa.pub (copy本地公钥到B，需要输入密码)

 

2008-11-11
用scponly创建一个chroot环境的sftp
在B上用root登录
以backup1为例
#mkdir /home/backup1/.ssh
#touch /home/backup1/.ssh/authorized_keys
#chown -R backup1:backup1 /home/backup1/.ssh
#cat /home/backup/.ssh/id_rsa.pub >> /home/backup1/.ssh/authorized_keys

========================================================= 

 

 

 

在B上用backup用户的命令:
#cd ~
# touch .ssh/authorized_keys (如果已经存在这个文件, 跳过这条)
# cat .ssh/id_rsa.pub >> .ssh/authorized_keys (将id_rsa.pub的内容追加到authorized_keys 中)

回到A机器:
# ssh backup@192.168.60.110 (不需要密码, 登录成功)

在a机上建立放脚本的目录

# cd /opt/lampp
# mkdir shell

copy文件到上面目录

# chmod +x mysqlbackup.sh

在本地/home/backup下建立本地备份目录

# cd /home/backup
# mkdir mysqlbackup && chown root:website mysqlbackup && chmod 0666 mysqlbackup

crontab 设置,每天凌晨3点执行

# crontab -e
0 3 * * * /bin/sh /opt/lampp/shell/mysqlbackup.sh

发下为脚本mysqlbackup.sh

 

#!/bin/bash
#每天备份mysql数据
#保留3天的备份包

#需备份的服务器名
server=test

#FTP主机
ftphost=’202.100.222.2′
#FTP用户名
ftpusername=test
#FTP密码
ftppassword=test

#ssh主机
sshhost=’202.100.222.2′
#ssh用户名
sshuser=backup
#备份存放目录
remotefolder=backup

#备份文件存放的目录
backuppath=/home/user/mysqlbackup
#备份文件名
file=${server}-mysql-$(date +%Y-%m-%d).tar.gz
#需备份的目录
sourcepath=/opt/lampp/var/mysql
#备份日志
logfile=${backuppath}/mysqlbackup.log

function Backup() #处理涵数
{
/bin/tar -czf ${backuppath}/${file} –exclude=${sourcepath}/mysql.sock ${sourcepath} #执行备份操作
echo -e $(date +%Y-%m-%d_%H:%M:%S)’:tar:’${backuppath}/${file} ${sourcepath}”\r” >>${logfile}

}

function Send()
{
#ssh,使用前请先做好配置
/usr/bin/rsync -av ${backuppath}/${file} -e /usr/bin/ssh ${sshuser}@${sshhost}:${remotefolder}/>>${logfile}

#cd $backuppath
#ftp -i -n open $ftphost user $ftpusername $ftppassword
#if [ ! [ -d BACKUP/$server ]]; then
#mkdir BACKUP/$server #如目录不存在则创建
#fi
#cd BACKUP/$server
#put $file #上传文件
#bye #退出
##!
}

echo -e ‘——————\r’ >>${logfile}
/bin/chown local:website ${logfile} && /bin/chmod 0666 ${logfile}
echo -e $(date +%Y-%m-%d_%H:%M:%S)”:server “${server}” beginning\r” >>${logfile}
/bin/rm -rf ${backuppath}/${serve}r-mysql-$(date +%Y-%m-%d –date=’3 days ago’).tar.gz #删除3天前的压缩文件
echo -e $(date +%Y-%m-%d_%H:%M:%S)”:delete backup file\r” >>$logfile
echo -e $(date +%Y-%m-%d_%H:%M:%S)”stop mysql\r” >>$logfile
/opt/lampp/lampp stopmysql >/dev/null 2>&1 #停止Mysql服务
Backup #调用处理涵数
/opt/lampp/lampp startmysql >/dev/null 2>&1 #启动Mysql服务
echo -e “\r\n”$(date +%Y-%m-%d_%H:%M:%S)”:start mysql\r” >>$logfile
Send

echo -e $(date +%Y-%m-%d_%H:%M:%S)”:mysql backup ok\r” >>$logfile
echo ‘ok’

http://blog.s135.com/read.php/269.htm

引用

# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process servesStartServers 10
MinSpareServers 10
MaxSpareServers 15
ServerLimit 2000
MaxClients 2000
MaxRequestsPerChild 10000

---

　　查看httpd进程数（即prefork模式下Apache能够处理的并发请求数）：
Linux命令：

引用

ps -ef | grep httpd | wc -l

返回结果示例：
1388
表示Apache能够处理1388个并发请求，这个值Apache可根据负载情况自动调整，我这组服务器中每台的峰值曾达到过2002。

---

　　查看Apache的并发请求数及其TCP连接状态：
Linux命令：

引用

netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

（这条语句是从 新浪互动社区事业部技术总监王老大那儿获得的，非常不错）
返回结果示例：
LAST_ACK 5
SYN_RECV 30
ESTABLISHED 1597
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057
其中的SYN_RECV表示正在等待处理的请求数；ESTABLISHED表示正常数据传输状态；TIME_WAIT表示处理完毕，等待超时结束的请求数。

---

　　关于TCP状态的变迁，可以从下图形象地看出：

状态：描述
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放
LAST_ACK：等待所有分组死掉

mysql不能启动，报找不到xxx.sock

kill -9 进程。不行
查看my.cnf配置。没错

看了一下error.log,发现没空间了

df -ks
du -hs /opt
/opt占了三十几G，原来apache日志一直没清过，新上的产品每天又产生近2G的日志。

把日志删了后就正常了.

修改apache
CustomLog combined /dev/null

在root用户下编辑启动脚本

vi /etc/rc.d/rc.local
#加一句
/usr/bin/rdate -s time-a.nist.gov

ntp比较麻烦点
crontab 可能造成时间不连续

time-a.nist.gov 注：美国NIST守时中心
time.join.uni-muenster.de

两台web受攻击
查看网页原文件变乱码

? 韂隨G?霻?0W赂*0z `似^嘙黊丬T曛-j?i蘦F;32阎齡?~?F€怈B B醲搷祸n_邸6v内u籊聠D/輾?鱒恃0缨}N焀?Η絆畏邴be?蓓L_?奟8E?盬QYY?S盐R欕飄犄婲
鹇H>?X莤T椾T樌?潅吲)尷? ls婼騴A硙錆扗J郋Vc6Z岘鯹埅?EI祳?’媵p燳^^錮獧騪瑡??dp€匲姈?(ae湅bU
SG 鉶D?藿拫?愿龛梔/ 哹?疰竪
呆(R]??g?*?狿>庲╚侐轎?f锈d楆?褳榋L 脡枢QU?饇p癳幸”蒼F?瓙? v痆赖◇Wo祂魺xQ楱Cljkk珤T 耞昗4:鸧?|荡鷊+﹙餽*pa牶f铟~嚒KU 髝瀣aP筄TF珵rzXY崂=w還
pK祙缞n?朕[?<蚞覊瑮? p丄Iv){J?鳚j鹝?嬠錚;呩嵭f!3??鸴褓汐濊攜辕﹖%?{9u?XM8]匟>巓苴紱x4|5]塯?酺x6|?蜁胕X舶?J菹m蘛[鹥t橥bxv肟阗x糧:藣甞NWf镂龕???f［酲4娈&枃溆曡稺fW柿4鮂銎HpXk6,槣十呌戠墘ュ欬峫dt箅組/謫?S宓囬
|:w-Q ё? 哈Y*昛|諃R!sk鈟?窀槤?輪ゲ晠硪zj ?僬ピj1蹈q黥]Xh%晉4{i~h髜. し^黤鴍dp饛碉5葇軓嚪甇l?玲_経?`G敌┅鉚F喝涩 磤?J鎰?E
溾?祲傱昭?”,€???X行銘d?淢?陮V硜間/蜞??透榏腙揬
?R极?(?C鏪嘵蕤?x珃Os)?皙〕?鱺鶯愜 e7?0鄽骱)Ev?4y/0(噌@?7遫?y楆?榋崰?秭 -穬kV P?莰 驽D恐簘w?yO泠=I壏Jp?Xer羚~?囇
[Qヲ 諎C@?賚b?
'3伤Ag墼欅
?尻Q饥2.VR<|?Z質a灬氅>馛m軺: ?籘KＡ郪轷4兝樵笟 W罹灓tm
d3,辖瀭?哨韅p隝.瘕淴%YX(BO^O鬞i栕兞濮縃榀Yи敛,牳?v/>燌9彤r
涗d?^?S-?@&q伅u枥孻?
cPo熇?單輕翱鰒Ζn繛8??U勺[週攽@鏡3抈0]橧Q蚾徽w￤F瓑菩橿滯a?l蚓6瞰 i?kt恝龌雰毤,/BG赵┹襹a祶同阑?N牎蠭??夘蝲&鯟8絉Ni礉┹躘?L?责翼?
w@葶溶蹭鰽甍u帆胋t(-?Ls薑鐟T┓枀?Ｑ敋盂缬???8??3冕涖?抵~遣沞ｆN盰?<5Q,N 漼?榍腹蛯??a<査m庈\箾庪嵌諅傻裫!?乕脩?囜:瞞耭跠b?茳踌7?Q?鮼此?
7? \37Z?>窟脬凭9絃”*鼀:{k胑垡F湫脬箩裦12蝉tbF矡3??姃匓1 E?螦暮1
浔vF+?~恲桚圬4车1y=z?邔?媤”#`mX痰踧{萵’qH苘в邉nGz@z?煍瘇阨嵌J;Q餎圉8=”莾?濢 ;灏??^ㄖ禘蹐,亄鎩wJ営藨:潓?士侔龥嵢匙菎?
??% P$ ?硈# ?z\腂篦沏?倏?偈x%籸浮賭;p豂??盷茎熍粹嶡嵀ff笐{瀵奇V榍?;8,D絒
ㄝ翍摟t渉h艥T擠
囔擓
d[莮?€?vΗ?z\? 荃R灆.疶繾h~擨?裀w嚟芕ⅨFn弴:靖愌1/j礲髄%夤>畋嘲??央`(湱?b蕶忡Lqv>覲?[1?(I剟烰逬-琝?d顢騚斣窄焼碼[E慤 p廗凈蔲n-z}?砺d膷巰?N爛+yD0bX実u\0封&蕗挙砆馈″Hb'E曎?p"鏳蹯u顶浫,
軽z 潥?封&鶂拡ep法-鹇xV犖矤:R夊食硼A3嗁h苧?剃ｙс鍓∑?3瞵??松 潀構G<ì妺櫑排眹p)+?€R鈜cef肕8 %慱E 鳒9?近4}GO穊?&vⅰ
x閥aQGv豝匝J郧囿]枞?
w Pu.竾 ‘
晋4蛋U襍?豭m!Sk?’鮠7攄讨>軲??
岴韬u靏s+?J铂?餽v-粸_x3??€扝
纆=祭?z*涁蓴醮v+禬窉迤鄐糞蛐墖懟zr嵔恇”[HA
?awh槹'匨d撀(鄩碣橇戙,?犵士 {蜻D6鶑^Kg6?=?=w鰻i|f騴a
$飬厤逡遴衅屦詪?
M渫f\ 擠A

\.D*慁?蔎踂?東 /粋?疥 ?pO
,YX:=?$湼Γ鏻胒綅坲钬X鳤p浯$珳牐#炼
@I4鬉 G/痎謖#nJ`?
?窯' 簵洏?
M钅/評?{H`"ZKD
?卐窋`4偬
帆户??嬰?f2犷攄]\xb{%#麤鷺q %檕?剪d???s櫕谠f,桘?[?粇#~悳jl羟辷?w錜魕笌?端
跘貕w* 溍ド澿H刻q姄8?v$?EB铋?迃T卿涊6"v缚憬掕b樘昴#=窇bo?溅劺卥e]Z?梗琏p焱硋?埨
‘薩?相葃?8胺?堔@辔轃}A{曜豃d?蹷&|盭p? J>%犺?
;z?Eon﨓nf-:2尳!磿h?7 抨3鼖閉,硘/Z)嵡^4v岷{$蠮6@ 縲枎~曎評?{|k’?€彎8?:醮钷唵1輪=蔵#?€厦?鶻z騄鵖=巜&瞲?>w縉 [lDz爛熸2p鐮痻}:9L[瞪>頓>?[⑦?H芪lk?427癰诵J&Cp!櫺q欁d妻鏶&劢 ?
Ml譥鎘芩^?悜,B 煍$防?Mz2?
峝?
?霊$z}!:る?v鎐"束P馈∧>T鐫灼睂崏鞎p鑻?=??稅?x逯z?O衞瘤?2? ?+nt3氤B伾On遴醝?
?l镧 ?C k踂
粃鲛D层鱌绤d瑪I7#?n禸燍a%;?
_K諜e? %裠g㏒掛fE:=H??瓘澫9萬?繻鏝?O鮸剌觭俕z湅&鬨?c焪(塗Y箏鞎[3偈-
瀋]褅Swt巔谿J矖店’阀?晏4?>&?|P繻輂]迓靋=?n?浬?芘珅+D/e居搈鞝n# ?鄼l”ΤS寝Wk&踂?頠Y雅??%s.z銦唠时?攄?鈹-彛?.餏?儿?> ./ 媵(觃鐔8??]g??f茊?|?
? ?#晻乡瀲契芏?_Ov?
83痸炝?钅2寡\r跎驈蘹f鮅?AL伫拤鞇3饓?悭z’C6鞎E煦烊?竰;9ZN脩q)禃沖觪?[6ⅸ/铥gO潳侵??t靪?墝dg!p蟸訣g6K壈炡幗櫿H稒亄y:淺紆谐啥搽?铨特铽櫳轜C
u嘛國e?
g痬~﹌R?#
%Y
UA煁\€巊&wt=嵧l?S厣?B cy境N兀圴睶鴾$€?u寭轀L'湀祵ML?製N[缟雎爛+嗸忳f煜粯?飩>謚?繑婳~
E爂梒镲擠?€?h9羊~ 篫?繂`^?鰓蘢遳@
焤鞠?
瘕身阺]?D绯爛OI”疛2uτｓC?Yb苸嬐L?
? c镻2S^G綥<<∕漓pmgj=3盘咚龎檢?bb殴瘷?
篙牎’^a/獦壠M(鄰d? 珘=柞
f+锻X蒷
|栿)| |歋?zi府lc?+Y|@ 3w?GO潨溄??lU7懇:8睋(繅?{坊檒?
裺=t驔軞瓹C煜O摑雮??蟔瀁K霥/胧
€2ｚA搁,ア焻摫z?%Q錎?鄑ジ _]%w宊醖f熶<猈`x/腈{yQ?臫e?儷?-=堨?阊茆餚zq鷩錵肅Z挖髼醴0備桙* @QTY莼陀??睖_抉C;S}伫?眺姃?筗2圽櫨盔瑸?╕@Q纯剒y駍RN撦z旝e鼑v辉?I*’梦踂\?贱O;屢蝴小诣靪偈鈜9?鯮?U?a /?饻忉Dw ?C’?铬[炿裯u?ュ咱N?x?嵍噱v??刁"+S?
愨`%r冊q8?Kr鷣=??n詩锤9?~A?0I罩j嘛矿n廕濄€]鋅T
?X秧
詀咐^d?
U酹q鄶
唄6S€S 繮y鏎 >?﹍硾m品〓t貭糺阑x?嗡+
_U6勯?ぅ?U懺W跓杩鳆玏鞮熶
h`?埯be?(衴劉>€緣G(汕?}屄i-`诖6嬅b1Z筕W氩洭齎嫞弇5:靨禋摺昔?姑T? 唈?詉塕麼?$檙?鏣%9@焰?/R?5\?

妱9x?o

机房检查确认是机柜中一台跑asp的机器被攻陷
拔掉其网线后没事了。

恭喜公司.com再此被百度收录。
网站改版后，由于目录和文件命名的改变，以前收录的URL就是404了，现需转发至资料备份服务器。
使用php的话效率低了，所以用apache直接转发。

#使用正则
RedirectMatch temp ^/(doc|news|parttimetalent|fulltimetalent|person|ebook)/(.*) http://222.222.222.222/$1/$2

#反向代理；对图片、js等目录都需处理，比较麻烦
#需开启proxy_module和proxy_http_module，费资源
#ProxyPass /doc/ http://222.222.222.222/doc/
#ProxyPass /Include/ http://222.222.222.222/Include/
#ProxyPassReverse /doc/ http://222.222.222.222/doc/

关于在转向时使用301还是302，可以参考
http://www.chinamyhosting.com/seoblog/2006/04/12/301-redirect/

如果想收录新站就用301,保持原站索引用302

发布新版首页时，高峰时
task达到800,cpu 60%
keepAlive off后
下降至3百多到，cpu 10~40%.
补上一张找不到的ICON后
下降至3百不到，cpu 10%.

404的图片对apache的进程和cpu还是有点影响的，10~30%左右