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

　　下面一一列举一些容量浪费的可能，并尝试分析其原因。

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

　　但是，这种备份方法，无法做到完全自动。多数需要人工干预。如果想和备份软件结合，备份软件只能对其export出来的东西，进行文件系统备份。这就使恢复变成了两个阶段。就是将备份软件备走的数据恢复到文件系统，再利用数据库工具进行恢复。备份软件不会，也不可能记录他备份了什么。如果你想知道备份软件备份了什么，你就需要为这个备份写一个日志。为你将来查找数据到底在哪提供依据。

　　数据库可以通过备份软件进行在线备份。而这种备份，通常是利用了数据库自己的备份工具。例如ORACLE使用了RMAN，INFORMIX使用了ONBAR，而SYBASE比较简单，只是DUMP和LOAD两个命令。这种备份不能对表进行恢复，一恢复就是整个库。但是备份软件对其备份的数据进行了很好的管理，你完全可以一次就将数据库恢复到某个你期望的时刻。

　　为了让备份更好的发挥作用。现在我遇到的所有用户，以及我们自己的实施习惯。都会对用户的数据库进行以上的两种备份。既把数据EXPORT出来，备份文件系统。又进行数据库的在线备份。这就导致了原本一份的数据，被复制成了两份。如果用户比较大，同时还拥有一个灾难中心。那么好了，这个数据就被复制了4份。这是用户购买了自认为海量存储设备后，没过多久就发现其存储容量不足的主要原因。目前，没有更好的办法来解决。

　　划分卷池策略不当

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

　　但是，这会带来一个优化时间窗口的问题。例如，两个策略由于保留时间相同而使用相同卷池。但是他们发起的时间非常或者比较接近。那么，由于上一个备份策略还没有释放磁带，新的策略已经发起了。备份软件就会调动一盘新的磁带来使用。这经常是偶尔发生的事情，但是，这盘磁带已经被lable，并且拥有数据了。在上面数据没有过期之前，该磁带上的空间，又会被长期闲置。

　　要解决这个问题，就必须对备份进行深入的观察。记录相同保留时间的所有策略的备份发起时间，完成这些备份的时间，这些策略备份窗口的成长，以及用户的需求等等因素，来进行规划这24小时，让相同保留时间的策略进行可以线性启动，保证磁带利用率。

　　手工磁带分配不当

　　我只veritas使用时间比较长。而且是新手到比较熟悉的过程。在这个过程中，新人通常都会有这样的毛病。他们虽然建立了SCRACH POOL，但同时还向各个卷池分配了几盘磁带。随着备份的进行，被手工分配的磁带全部被用光了，备份软件会自动调动SCRACH POOL中的磁带到策略对应的卷池来保存数据。手工调动进来的磁带随着时间的流逝，慢慢都过期了。但是因为他们不是通过SCRACH POOL调动进来的，所以，他们不能为其他卷池所用，只好无所事事的闲置在那里，等待被重新利用。如果刚好赶上这个策略的备份容量较小，过期时间较长。则他们闲置的时间就会更长。

　　要解决这个问题，只有等待该磁带过期，然后手工把他们从卷池中删除，然后再加到SCRACH POOL中。但这需要你有足够的耐心和记性。若运气不好，策略比较多，卷池也比较多。那就只有看着了。

　　卷池建立过多

　　我之前也有过一个错误，那就是建立了很多卷池。几乎一个策略一个卷池。当我拥有100多个策略之后，我发现，我的磁带立刻就不够用了。每建立一个卷池，就意味着你需要为这个卷池调度一盘磁带。因为，卷池越少，磁带的利用率就越高。

　　小容量备份

　　小容量备份，长过期时间，也是磁带被长时间搁置的原因之一。虽然这不是很重要。小数据量，会导致多个备份堆积在一盘磁带内。而这个磁带的过期时间是以最后一次备份来计算的。因此，再小备份的卷池，也最少需要2盘磁带来进行中转。所以，在考虑容量的时候，这个因素一定要考虑在内。