我们现在所使用的legato networker备份软件基本上都是7.x的了。基于7.x本人只是看过一些文档，并没有现场维护过7.x的。所以，并没有足够的发言权。不知道基于6.x 上遇到index的问题，在7.x上不知道有没有解决。
一般备份情况为从上线以后到现在所采用的的pool的划分方式是以被备份主机为目标客户端进行划分的。将被备份的主机做为client将备份服务器做为server。legato networker被分为server端和client端.client端依托server端发起备份任务，client的备份方式和策略是由server端来进行制定的。但是，在按照备份client进行pool的规划的时候，随着时间的推移上线的系统的时间越来越长了。数据量一直在持续增长。反之，所带来的备份方面的问题就暴露出来了。所以，我们最早制定的按照主机来进行pool划分的方式，就会出现磁带紧张的问题了。由于我们为磁带制定的回收期到了的情况下，由于index的回收期和数据的回收期不一致的问题，会引起出现磁带不能回收的现象这样对磁带的浪费比较大。所以，我们必须考虑到对pool的方式进行正确的规划，希望可以解决磁带已经到回收期但不能回收的问题。
所以为了确保备份任务的正常备份，有的时候需要手工进行备份任务的干预，同时，将一些数据量比较大，备份周期比较频繁，数据重要性不是很高的备份任务进行了相应的备份策略的调整，将备份周期调大。同时，将一些可以手工进行重新回收的磁带进行了手工的回收。现在基本上能够保证备份任务的正常进行。但是，考虑到我们的数据量还会继续增大呢？我们将会怎样呢？
所以呢？简单的办法就是想对备份策略和pool的方式进行调整。
因为备份数据磁带的重复使用主要是回收期的所带来的问题。所以，将所有回收期一样的备份策略归入到同一个pool中。这样就可以减少因为回收期所带来的磁带占用的问题。这个能够解决回收期的问题吗？暂时也许可以解决，但是，随着时间的推移。会和当开始建立备份时候的问题一样的。所以，问题不会得到解决。
因为，引起数据磁带不能正确回收的原因还是index的回收期和备份数据的回收期不一致的原因。
所以， 需要将index和数据进行分割来进行备份。因为，系统所存在的回收期的问题是因为在磁带上备份的即有数据又有index .由于数据和index的回收期限不一样所产生的回收奇异。这样将index和数据进行分开备份会解决这个问题。
这样做可以解决磁带的回收期的问题。数据磁带的pool可以正常的回收和备份。但是，同样又会有另一个问题出现，就是在index pool中会出现大量的磁带。如果，你的备份任务越多和备份频率越大，你的index pool中的磁带会越多。这样其实，还是会产生大量的磁带。但是，这样的磁带量是我们能够容忍的。比如用LTO（100~200G）的一年大约是15盘-20盘左右。而LTO3（400~800G）的话。需求量会更少。基本上可以解决这个问题。
但是，把index单独建立一个pool的话，同样还会带来另一个问题的出现。那就是丢失index db库的问题。如果，最后一次的备份是失败的。这次备份任务的index并没有写成功。如果这个时候重新启动legato的话，就会出现Can’t fetch old volume这样的信息。因为，你的index信息被破坏了。重新启动以后并不能通过这个index来建立db。所以，这个时候就必须用mmrecov来进行恢复。但是，由于你已经建立了index pool所以，进行这个恢复是非常容易的。但是，也带来的问题是会丢失一部分数据。
所以，在建立index pool之后，在备份任务失败的情况下，请不要重新启动legato networker。不知道这个问题在7.x上是不是已经进行了修正。
还有用legato networker进行oralce数据备份的情况下，（引导RMAN备份）如果不成功的话。需要手工kill nsrnom启动的相关的进程。因为，如果不这样的话。会引起oracle的锁表。
阅读(1000) | 评论(0) | 转发(0) |
