Networker

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

2008-11-06 14:09:08
Subject: Re: [Networker] Changing the browse policy on a clone in 7.4x
From: Tim Mooney <Tim.Mooney AT NDSU DOT EDU>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 6 Nov 2008 13:06:31 -0600
In regard to: Re: [Networker] Changing the browse policy on a clone in...:

When you say still have a copy of the index, is this governed by the
retention policy?

Sort of.  See below.

 Or is the index removed after the browse policy
period expires?

The client index entries are purged on a periodic basis (nsrim runs
automatically, see the man page for it).  Once the browse period passes
for a saveset, the client index entries will eventually be purged
from the client index.

Assuming you're backing up your indexes (that's the default, you would
have had to make changes for that to not be the case), you still have
a copy of the index on tape (or some other type of backup volume).

 If it's the latter can I use a command like nsrck -L7
-t <date> <client> and Networker will prompt me to load the appropriate
media?

No prompting necessary.

 If not how else would I know where the index was?

I know it's a little confusing and I'm probably not the best person to
explain it, but basically there's a slight difference between browse and
retention that's confusing you.

When a saveset passes its browse time, an automated process (nsrim)
eventually comes along and purges the records from the client index.
"browse" has a very direct control on how long client index entries
stick around.

It's NOT the same for retention.  Although retention controls the minimum
amount of time that the *media* database keeps a record for where a
saveset is, there is no retention equivalent to nsrim.  As long as you
still have a tape, the media database will continue to have information
for what savesets are on that tape, even if every single saveset on that
tape has passed its retention period (and the tape shows as "expired" in
the admin GUI).

Media database entries don't go away until and unless

- the tape is recycled, at which point all of the savesets that were on
  that tape are deleted from the media database

or

- the tape is deleted from the media database (manually), at which point
  all of the savesets on the tape are also deleted

or

- individual saveset entries are deleted from the media database (again,
  manually).


So, no matter what your browse or retention period is, as long as you
have a tape (and you haven't purposely, manually deleted the tape or
individual savesets on that tape), you will have entries in the media
database that tell where the savesets are.

Assuming an index saveset is one of the savesets on that tape, then
nsrck -L7 -t time -c client knows exactly what tape is needed to find
the index saveset.  It will tell nsrjb to load it, fast forward to
the right spot on the tape, and then load the index saveset, merging
the contents of what's on tape with what's currently in the online
index [1].  As soon as that completes, you can again browse.

Tim


[1] Because you originally asked the question with regard to cloning and
you're hopefully clone both the savesets you care about and the index
savesets for the client(s) in question, the complication that I'm
glossing over won't apply to you.  That complication relates to what
happens when you still have a tape with an index saveset on it, but
some of the savesets described by the index saveset are no longer
available because they were on other tapes that have already been
recycled.  In that case, you can still load the index, but if the
original saveset are no longer available, either the initial merge
process or some other process will get rid of index entries for which
the savesets no longer exist.

In regard to: Re: [Networker] Changing the browse policy on a clone in
7.4,...:

Just to clarify a save set recovery is therefore necessary for the
cloned save sets?

Not necessarily.

Everything David said is (currently) true, but if you still have a copy
of the index for the client in question on tape, you can very quickly
load
the index using nsrck -L7, and then be able to browse and recover what
you
need.

So, if you need to keep a saveset around for a long time, it pays to
also
keep a copy of the relevant index saveset(s) for the same length of
time,
because having the client index makes it quick and easy to get back to
the point where things are browseable.

Tim

-----Original Message-----
From: David Dulek [mailto:ddulek AT fastenal DOT com]
Sent: 05 November 2008 13:57
To: EMC NetWorker discussion; Esson, Paul
Subject: Re: [Networker] Changing the browse policy on a clone in 7.4

You can't.  The browse policy is on the ssid not the cloneid.  Also,
the
browse policy can not be longer than the shortest retention policy.

I wonder if that is addressed in 7.5?

On Wed, 2008-11-05 at 12:35 +0000, Esson, Paul wrote:
Folks,



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?



Regards,

Paul Esson
Redstor Limited

Direct:               +44 (0) 1224 595381
Mobile:          +44 (0) 7766 906514
E-Mail:          paul.esson AT redstor DOT com
Web:            www.redstor.com

REDSTOR LIMITED
Torridon House
73-75 Regent Quay
Aberdeen
UK
AB11 5AR

Disclaimer:
The information included in this e-mail is of a confidential nature
and
is intended only for the addressee.  If you are not the intended
addressee, any disclosure, copying or distribution by you is
prohibited
and may be unlawful.  Disclosure to any party other than the
addressee,
whether inadvertent or otherwise is not intended to waive privilege
or
confidentiality.


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

______________________________________________________________________
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




--
Tim Mooney                                             Tim.Mooney AT ndsu DOT 
edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

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