分类: 服务器与存储
2008-06-12 22:40:53
但是,这种备份方法,无法做到完全自动。多数需要人工干预。如果想和备份软件结合,备份软件只能对其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盘磁带来进行中转。所以,在考虑容量的时候,这个因素一定要考虑在内。