Networker

Re: [Networker] Changing the browse policy on a clone in 7.4

2008-11-05 13:20:14
Subject: Re: [Networker] Changing the browse policy on a clone in 7.4
From: Davina Treiber <Davina.Treiber AT PEEVRO.CO DOT UK>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 5 Nov 2008 18:17:33 +0000
Esson, Paul wrote:

Our set-up is Networker 7.4SP2 on AIX 5.3.  We have commissioned an EMC
Disk Library (DL4602) and also have a Quantum Scalar i2000 tape library.
The intention is to write save sets to the DL in the first instance then
clone them to the i2K.  In 7.4 I know we can change the retention policy
on the clone to be different from that of the original save set.
However, how do we change the browse policy for the clone so that we
do not have to do a save set recovery for these longer retention
backups?  Can we set a browse policy on the original that is greater
than the retention policy to propagate this to the clone?

This is a problem for those environments where backups are written to an EDL and later moved to tape. I am trying to do the same thing at the moment for a couple of customers and working out the options. The new(ish) functionality of having different retention policies for the same save set in different pools is wasted because of the issue with the browse time having to be not later than retention.

As I see it there are a few choices:

(1) Write the save sets to the EDL with your desired (long) browse time, and use nsrstage rather than nsrclone to copy them for tape. There are two disadvantages to this approach. The first is that you don't get the data copied to tape until it has been on the EDL for a few days or weeks. The second is that when you need the EDL to release space for new backups it is probably busy staging your older data.

(2) Write the data to EDL with your desired (long) browse time, clone it to tape, then use a script to delete the save set on EDL when it reaches the desired retention time, after checking that it has been successfully cloned.

(3) Write to EDL with a short retention time, clone to a pool with a longer retention, then do some jiggery pokery with nsrck -L7 to repopulate the index. Not a pretty solution.

None of these solutions are very good, but I think I'm going to have to go with option 2 for the ones I am doing. Really we need EMC Engineering to come up with a better solution. Perhaps we need a relaxation of the rule where browse cannot be later than retention. Perhaps the best way would be if browse could be later than retention for any particular clone, but not longer than the longest retention - that would work.

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER