一些想法:关于备份

有一批备份计划的队列,分发在不同的备份机上运行
一台主备份机m台备份机对应m*n台服务器
1.所有的备份机去一台主备份机的数据表中取得属于自己的备份计划(因为是隔天备份，所以今天的备份计划跟昨天不同，但是跟前天基本相同)
2.在主备份机坏掉的情况下，各备份机要能正常的执行自己的备份计划
3.在主备份机更新以后，各备份机要在最迟下个工作日时更新到自己的计划,且不能打乱原先的隔天备份计划，
4.每个备份机的备份实时进度应该实时反馈到主备份机的数据表中
5.因为备份机和主备份机可能不在同一个机房，所以存在备份机可能和主备份机网络中断的情况，此时的备份实时进度无法更新到主备份机，等网络畅通以后再更新进度（网络中断的时间可能会超过一天)
6.任意备份机的执行队列都有可能会产生中断，例备份机在执行打包作业时重启了，要求重启以后作业能不手动干预的情况下继续执行
7.备份机的传输队列和打包队列应该是异步执行的，当一个传输队列进行完以后，打包进程应试捕捉到这个队列是可以打包的，
8.当一个传输队列运行时间超过一定阀值，应该报警
9.传输队列和打包队列的线程数应该是可设置的，同一时间可以走几个传输线程，和打包线程
10.每个失败的任务应该记录详细的日志记录，并且生成可重复运行的脚本

其他的要求
11.备份的文件是通过异机传输过来的，要核实传输前的文件大小和传输后的文件大小是否有异常
12.备份的文件如果是SQL2008的备份文件不压缩直接打包，如果是SQL2008以前的BAK文件则压缩打包，如果是MYSQL的GZ包则按日期筛选文件打包
13.需要比较并记录打包前后文件的大小，如果是分卷打包，需要记录每个分卷的信息
14.备份的文件可能是通过本地去拷回来的，也有可能会是异机推送过来的
15.如果是MSSQL的BAK文件，要联机验证BAK文件的可用性
16.判断是否是需要刻盘的文件，如果是则需要记录文件的分卷信息并入库到主备份机同时登记文件的MD5信息

===========================================================================================
针对以上的
A.关于隔天备份:
原先是想每个备份计划在主备份机的总表上就显示标识一个字段 取0,1值，当前的日期 然后2011-1-1号得到的天数除2求余
后来又想到可能有每天备份的计划，所以加上2这个标识值,如果是2则直接运行
采用哪一种？
应该会是第2种，因为可扩展性强点
B.关于主备份机的网络中断：
各备份机每天第一次运行时去主备份更新一次备份列表，如果失败，则继续原先本地保存的计划
现在的问题原先的备份计划是保存为本地的一张表呢，还是本地的一个文本文件
表的好处是查询方便，读取和更新都很便利，缺点是如果备份机上没装SQL呢，如果备份机上的SQL服务停了呢
同理每台备份机上的日志保存在表里呢还是文本文件里呢？
到底哪个比较好
偏向于第1种用表记录，因为简单点
C.关于多线程的：
因为传输线程和打包线程的开始时间不一样，需要两个线程调度。
而这两个调度是互相通知呢，还是不通知（不通知的情况下，第一个线程更新一个标识位，第二个线程取标识位来判断）
前一种方法存在潜在的，通知没送达的问题，第二种方法，则需要第二个线程调度隔一会取一次标识位，这点挺恶心的
偏向于第2种用标识位，因为简单点：）
D.关于备份机上的中断
在备份机重启，资源耗尽得情况下引起的程序中断，如何保证程序一次触发时恢复中断前的状态
如何在重启后，让程序运行，计划任务触发还是写成WINDOWS服务，如何避免资源浪费
偏向于第2种采用计划任务的方法,因为灵活度高一点

闷头想了一上午，决定把这些写下来。等完事以后验证一下这时候的想法都有哪些问题