备份系统已经成为各个大型用户的热门系统。几乎所有具备数据的部门，都会提出备份要求。但是，随着备份量，备份客户端，备份策略的增长，备份窗口越划越细，备份数据越流越乱。一个拥有10T容量的数据库，往往顶多保存了1-2个T的数据就没有空间了。反过来，当一个系统出了问题，却发现原有的备份策略，其实并不适合自己。导致了大量无用数据被保留下来，而真正有用的数据，却没有及时得到备份。
 
　　下面一一列举一些容量浪费的可能，并尝试分析其原因。

　　面对数据库，多数电信，联通，金融用户，在正式上线备份系统之前，就已经有了备份意识，并且都有一定的规定与措施。这种备份通常是利用数据自身功能把数据EXPORT出来。这样做最大的好处，就是可以进行最小到表的恢复。而目前大多数备份软件，都只能最小到库恢复，而对表无能为力。

　　但是，这种备份方法，无法做到完全自动。多数需要人工干预。如果想和备份软件结合，备份软件只能对其export出来的东西，进行文件系统备份。这就使恢复变成了两个阶段。就是将备份软件备走的数据恢复到文件系统，再利用数据库工具进行恢复。备份软件不会，也不可能记录他备份了什么。如果你想知道备份软件备份了什么，你就需要为这个备份写一个日志。为你将来查找数据到底在哪提供依据。
 
　　数据库可以通过备份软件进行在线备份。而这种备份，通常是利用了数据库自己的备份工具。例如ORACLE使用了RMAN，INFORMIX使用了ONBAR，而SYBASE比较简单，只是DUMP和LOAD两个命令。这种备份不能对表进行恢复，一恢复就是整个库。但是备份软件对其备份的数据进行了很好的管理，你完全可以一次就将数据库恢复到某个你期望的时刻。
 
　　为了让备份更好的发挥作用。现在我遇到的所有用户，以及我们自己的实施习惯。都会对用户的数据库进行以上的两种备份。既把数据EXPORT出来，备份文件系统。又进行数据库的在线备份。这就导致了原本一份的数据，被复制成了两份。如果用户比较大，同时还拥有一个灾难中心。那么好了，这个数据就被复制了4份。这是用户购买了自认为海量存储设备后，没过多久就发现其存储容量不足的主要原因。目前，没有更好的办法来解决。

　　划分卷池策略不当

　　通常为了节约磁带，提高磁带利用率。我们都会以保留时间来划分卷池。因为相同保留时间的数据，备份软件是不会更换磁带的。有些用户的单个库或文件系统很小，只有几十或者几百MB。而一盘LTO2磁带有200GB。一次全备份以后，这个磁带就被搁置了。这个磁带99%的空间被闲置，造成了浪费。而采用按照保留时间来划分卷池的方法。就可以有效的避免这个问题。

　　但是，这会带来一个优化时间窗口的问题。例如，两个策略由于保留时间相同而使用相同卷池。但是他们发起的时间非常或者比较接近。那么，由于上一个备份策略还没有释放磁带，新的策略已经发起了。备份软件就会调动一盘新的磁带来使用。这经常是偶尔发生的事情，但是，这盘磁带已经被lable，并且拥有数据了。在上面数据没有过期之前，该磁带上的空间，又会被长期闲置。
 
　　要解决这个问题，就必须对备份进行深入的观察。记录相同保留时间的所有策略的备份发起时间，完成这些备份的时间，这些策略备份窗口的成长，以及用户的需求等等因素，来进行规划这24小时，让相同保留时间的策略进行可以线性启动，保证磁带利用率。

[1] [2] 下一页

【责编:Chuan】