Networker

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

2008-11-06 12:35:16
Subject: Re: [Networker] Changing the browse policy on a clone in 7.4
From: "Esson, Paul" <Paul.Esson AT REDSTOR DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 6 Nov 2008 17:31:57 -0000
Davina,

Looking at option 2, how might I correctly identify the save sets on the
EDL for deletion?

Regards,

Paul Esson

-----Original Message-----
From: Davina Treiber [mailto:Davina.Treiber AT PeeVRo.co DOT uk] 
Sent: 05 November 2008 18:18
To: EMC NetWorker discussion; Esson, Paul
Subject: Re: [Networker] Changing the browse policy on a clone in 7.4

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.



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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