LinuxVPS自动备份脚本(优化版)

网络上大家都在使用的一个自动备份的脚本(原作者应该是猫言猫语),我自己也在用,经过无数次的使用后发现此脚本存在着一定的BUG(长期使用此脚本的朋友肯定知道BUG在哪里)。自己把脚本改了一下,加入了一些判断,使脚本更加智能化。

改进内容:
1,避免了忘记检查本机是否安装FTP软件导致备份失败的BUG;
2,避免了本机忘记创建/home/backup目录导致备份失败的BUG;
3,去掉了将数据库发送至邮箱的过程;
4,网站文件和数据库不再分开,将压缩至同一个压缩包内;

直接把以下脚本复制到/root/backup.sh

#!/bin/bash
#你要修改的地方从这里开始
MYSQL_USER=root     #mysql用户名
MYSQL_PASS=         #mysql密码
FTP_IP=             #远程ftp地址
FTP_USER=           #远程ftp用户名
FTP_PASS=           #远程ftp密码
FTP_backup=         #远程ftp上存放备份文件的目录,需要先在FTP上面建好
WEB_DATA=/home/wwwroot     #本地要备份的网站数据
#你要修改的地方从这里结束

if [ ! -f /usr/bin/ftp ]; then
    yum install ftp -y
fi
if [ ! -d /home/backup ]; then
    mkdir /home/backup
fi
 
#定义备份文件的名字
DataBakName=Data_$(date +"%Y%m%d").tar.gz
OldData=Data_$(date -d -5day +"%Y%m%d").tar.gz

#删除本地3天前的数据
rm -rf /home/backup/Data_$(date -d -3day +"%Y%m%d").tar.gz
cd /home/backup
 
#导出数据库,一个数据库一个压缩文件
for db in `/usr/local/mysql/bin/mysql -u$MYSQL_USER -p$MYSQL_PASS -B -N -e 'SHOW DATABASES' | xargs`; do
    (/usr/local/mysql/bin/mysqldump -u$MYSQL_USER -p$MYSQL_PASS ${db} -q --skip-lock-tables | gzip -9 - > ${db}.sql.gz;
	echo dumped /home/backup/${db}.sql.gz)	
done

#将导出的数据库和网站目录压缩为一个文件
tar zcf /home/backup/$DataBakName $WEB_DATA /home/backup/*.sql.gz

#删除本地已导出的数据库
rm -rf /home/backup/*.sql.gz
 
#上传到FTP空间,删除FTP空间5天前的数据
ftp -v -n $FTP_IP << END
user $FTP_USER $FTP_PASS
type binary
cd $FTP_backup
delete $OldData
put $DataBakName
bye
END

继续阅读

Welcome to Peer1

This blog is under peer1 now. 换到了所谓的贵族机房……

上一家Oneasiahost也很不错,虽然是OpenVZ的,但20多天来没有宕机过,稳定性非常好;且PING值十分优秀(走PCCW线路),是个不错的服务商。

现在换到了某家的Peer1,性价比相对Oneasiahost更高,先用着看看吧。

Kagoya vps 1G方案测试

Kagoya是日本少数支付境外用户购买的VPS商家,基于OpenVZ技术。今天购买了Kagoya 1G方案(最低套餐)的VPS,价格为840日元,折合人民币56元左右。配置是3核、1G内存(Burst到2G),200G硬盘。以下是一些测试数据:

1,PING测试
全国范围有不同程度的掉包,甚至从美国、香港PING过去依然会掉包。看来线路的确很烂。

两张17CE测试图(点击可放大),测试时间为下午4点左右。
17ce测试

17ce测试

补充:晚上19:30再次测试了一下,北京电信PING值高达300-500ms。

2,网络、硬盘测试
网络非常一般,硬盘灰常给力! 继续阅读

关于ChicagoVPS最近的宕机事件

最近由于SolusVM控制面板爆出了漏洞,不少VPS商家的数据被泄露,ChicagoVPS便是其中之一。我从网络下载了一份据称是ChicagoVPS的数据库,搜索了一下,里面居然真的有我的登陆邮箱以及密码等信息。

在以前,ChicagoVPS真的可以说上是VPS里面的优质商家,特别是它家的Xen,我的三个Xen在线率均在40天以上,其中有两个在线率超过80天。而且价格十分优惠,当年用优惠码买到的1核512内存的Xen仅3.5刀。性价比自然是不言而喻。虽说芝加哥是在美国中部,但我用webkaka测试过,国内大部分城市访问速度非常优秀。

可能是因为用上优秀主机了吧,百度不久前给了本博客较高的权重,有几篇文章被排在前面,流量又恢复到了1000IP以上。这自然是十分高兴。可怎么都没想到,会冒出来这么一档子事。

本来在6月18号,ChicagoVPS的数据库就被黑客爆了出来,我也在19号拿到了数据库,并确认了自己的信息也在里面。这时我并不担心什么,因为自己的VPS一直坚挺,而且自己在VPS上作了大量安全设置,不仅改了SSH端口,也禁止了root登陆,黑客无论如何也无法登陆我的VPS的,还部署了备份脚本,就算VPS被删除我也可以轻松找回数据。

可有时候偏偏事与愿违!20号夜里我发现本博客所在的Xen被莫名其妙关闭了(绝对不是被黑客删除了),一直很信赖ChicagoVPS的服务的,我想,应该很快就会恢复吧!于是没管它。直到第二天上班,仍未恢复,我意识到了什么!幸好我部署了备份脚本,脚本每天会自动把网站文件和数据库都远程导出到Godaddy的免费空间里,去Godaddy取回来便是!可当我登陆Godaddy免费空间的时候,发现了问题!网站文件倒是还在,数据库文件只有45K! 继续阅读

公布一个奇葩VPS:dream.jp/smartvps.cn

dream.jp/smartvps.cn好不好?dream.jp/smartvps.cn垃圾,dream.jp/smartvps.cn骗子。好了,开头先做一段SEO。现在开始讲述正题。

一提到日本,可能心里都会冒出几个感觉:友善,亲和,文明,礼貌。不知道从什么时候起,开始关注日本的VPS了,心里总有个感觉,再不济也是亚洲线路,速度也比美国的快吧

那天不知道怎么就逛到http://smartvps.cn这家了,查了一下,居然还是家大公司DTI旗下的产品,看来不用担心跑路了。又看了下价格,512M内存的日本VPS只要490日元(折合人民币40元不到),于是立即下手。开通还挺快。不到5分钟就开通了。

开通以后当然是万分欣喜的各种测试了,首先是看了看CPU,不看不要紧,一看顿时就闪瞎了我的眼!
垃圾的smartvps.cn 继续阅读

512M VPS上Apache性能和内存优化

最近廉价的VPS有越来越流行的趋势,但是很多廉价的VPS很多只有512M,甚至更少的内存,而Apache和MySQL这些建站必备的软件,又偏偏都是内存消耗大户,所以如何优化本来就不多的内存空间,就显得额外重要了。

注:本文是抓抓自己的经验之谈,没有什么权威性,欢迎理性的讨论和评价,拒绝出现诸如Nginx比Apache牛X很多之类的口水仗,谢谢。

虽然抓抓最喜欢和最熟悉的Linux发行版是Gentoo,但是通常在使用VPS时,我还是会安装主流的CentOS 5 32Bit版本。选择CentOS是因为CentOS是从Redhat演变而来,所以对大多数服务器软件的兼容性还算不错,比如Kloxo就可以在CentOS下面进行简易的一键安装,等等。而32Bit是因为可以避免使用64Bit的发行版而造成的诸多稀奇古怪的问题,相当稳定而且性能几乎没有什么差别,并且因为内存不超过4G而无需用到64Bit的寻址。

好了,言归正传。对于低端的VPS来说,因为内存本来就不是非常充足,所以如果你对Linux服务器平台的架设非常熟悉的话,完全可以不用什么控制面板;如果是一个初学者,出于方便的考虑,可以安装轻型的Kloxo控制面板,功能强大,内存占用少(大约4M~8M),除了功能排版有些混乱之外,其他该有的功能都有,不该有的功能也有,非常实用。

在优化Apache/MySQL之前,首先可以关掉一些不必要的后台守护进程,比如ClamAV(一个杀毒软件),你可以运行chkconfig –list查看哪些后台守护进程是不必要的,当然很多东西取决于你的具体应用。比如如果你不是经常登陆Kloxo,可以把Kloxo关闭;如果不发邮件,可以关闭QMail,等等。如果碰到一些自己不熟悉的进程,千万别忙着下手,先去Google一下,以免出现其他预料之外的问题。关闭自动启动可以使用chkconfig 守护进程名 off,但是内存中已经运行的守护进程不会被关闭,需要运行service 守护进程名 stop进行关闭。 继续阅读

Centos出现 rm: cannot remove x: Read-only file system 的解决办法

最近自己的VPS之一出现了 rm: cannot remove `03/03a707c4dce673e6e33218917d710388.cache’: Read-only file system 的错误。自己谷歌了一下,把问题解决了,简单记录一下。

df -m  #查看文件系统的划分,最大的那个,便是系统使用的文件系统
mount  #或者这样查看文件系统的划分
fsck -y /dev/mapper/VolGroup00-LogVol00   #执行修复文件系统
shutdown -r now   #修复完成后重启系统

然后再次执行 rm -rf 就不会再提示 Read-only file system 了。