俺们现在维护的一个项目的数据库系统大致是这样的：

# 定期（频率还是比较高的，因为特定需求）从若干客户端上传数据到中心服务器，
数据量每天几万条吧。

# 中心服务器的主库存放一定时间内的流水数据，超出此期限的流水数据
由SQL Server 的计划任务转移到历史数据库中；
统计类数据则不受此限制；

# 不算事务日志文件，主库的常规大小约为6GB，历史库则比较大，已经积累到23GB

# 还有其他若干个库，此处略去不提

现在的备份策略是：

# 有备份软件，用于备份数据库（实际上还是用SQL Server 的 Backup命令实现）
该软件还可以导出流水数据，但实际上业主单位较少使用该软件

# 使用 SQL Server 本身的计划任务外加存储过程，定期（每周若干次）转移数据到历史库

# 使用 SQL Server 本身的管理功能，建立定期备份数据库和事务日志的维护管理计划，
基本上是每周日完整备份一次数据库，其他一至六备份事务日志

# 由于磁盘阵列空间也有限，这些数据库和事务日志的备份循环时间是一个月（四周）

现在的感觉：

# 历史库数据增加到很大的程度，每次的维护计划都要维护备份这个历史库和主库
产生的库备份和日志都非常大，极大地占用了阵列的空间，搞到硬盘资源有些紧张

# 由于库文件相对庞大，实际上在转移数据和备份文件时，CPU和内存资源占用较大，
个别时候影响到其他在服务器上的应用

请大家针对这个现状和备份策略，看看有没有什么可以改进或注意的地方？