公司有一个行业性的招商网站,放在万网的独享主机上,万网的机房在北京. 公司在浙江,本来是一月手动备份一次网站跟数据库的,现在需要更频繁的备份数据库跟网站文件,如果还是按手动在服务器上打包网站与数据库,然后ftp下来,由于现在网站数据库记录在10万+,网站文件总大小也过10G,压缩后的大小也在5G左右,因此每天ftp下载很占时间,况且公司上网是ADSL,10台电脑带宽一分,ftp下载速度经常在10kb-200kb之间,200kb只在早上9:00前才有的速度.因此每天来一次整站打包压缩后再下载根本不合适,况且公司没专门网管,一边做备份,一边还要写程序根本就忙不过来.
基于以上原因,采用整体打包的办法,一个月来一次还好,但是一天来一次就不行了,于是就考虑增量备份,即每天把变化的文件下载下来,那些没变动的就不去下载,这样一来每天需要下载的数据量就很少了,按照这样的思路我在网上找了些备份工具,比如:super Flexible File Synchronizer ,一个很不错的软件,因为备份服务器(公司里的电脑)ADLS上网,没固定IP,于是就把SFFS按装在本地电脑,web服务器配置ftp,但是问题来了由于公司站点目录里文件太多,SFFS经常出现无法响应,因为SFFS是一次性获取目录里的所有文件列表,接着跟本地的文件比较修改时间,因目录里文件已经过几万,一个列表获取操作经常无法完成,导致同步无法继续,其他一些能找到的ftp软件也是因为不是专门为网站备份设计的,往往存在这样那样的问题,3天时间找下了,我决定放弃使用现成的软件而是自己使用.net开发一套.
既然决定自己开发了,那么几个技术点必需解决,首先是大文件下载. 要有续传功能,另外要确定增量备份时那些文件需要备份,
这个首先想到的是采用FileSystemWatch记录目录里的文件变动,在把变动的信息发送的客户端,而客户端根据变动做相应的操作. 然而目录是连续变动的,fsw就需要连续记录变化并把变化反映到客户端,因此只要期间出现错误,将影响到后继的同步,即两次同步操作间有比较大的联系,具体的在电脑上测试了下
使用FileSystemWatch监视网站目录,将变动记录到MSSQ(消息队列),然后备份服务器定期访问队列,根据里面的信息进行文件同步,每处理一条信息就移动掉,感觉很简单,不过处理起来就不那么容易了,FSW产生的命令你不能简单的在客户端重复,你需要对这些命令的先后顺序,组合做一些处理,比方你修改个文件,那么FileSystemWatche经常会触发2-10次不等的同一事件,当时我还考虑记录重名命等操作,结果搞的是烧焦烂额,情急下不得不寻求另外简单的解决办法(当然上面的方法是可行的,只是你需要考虑的东西比较多).
新想到办法是采用数据库,因为目录里的文件是按时间联系变化的,那么在某个时间点我们记录下目录里文件的状态,待下次同步时只要比较目录里的文件跟,数据库里的记录则可以得出那些文件是修改了,那些文件是增加的, 需要注意的是,由于是备份,网站上那些被删除的文件(不管是有意无意,还是恶意的)是不做记录的,另外对于文件重名,可以不去管,当新文件下载就是,公司网站多是些图片或文本文件,多一个少一个下载不是问题,而文件夹同重命名基本是不会发生的,尤其是那些有几万个文件的文件夹一旦重新命名将会导致几万个文件下载,但是这个情况多半发生在恶意重命名,好在文件夹一但被重命名经常导致网站访问问题,或者同步程序出问题,这个很容易就能被发现,并及时得到处理,而且,同步程序不是比较目录下全部的文件,而是按照文件更新时间前后取前几个文件(具体的看这个文件夹每天具体的增量,公司目前前取100则可),因此即使含有大量文件的文件夹被重新命名,造成的文件下载也就在指定范围内,即使全部下载,由于同步程序采用单线下载,只开通一个tcp连接,对一台web服务器来说并不会造成多少影响, 一般来说网站稳定运行后很少会去改目录名称,除非程序被重新开发或部属,在这样的情况下只要重新初始化下数据库里记录的文件状态即可继续运行.
以上方式的好处时,简单化了同步操作,并且使2次同步操作之间的影响降低