Extremely good comments.

Thank you for giving me that additional perspective on the use of
scratch pools with NW. I agree with everything you said.

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Davina Treiber
Sent: Thursday, March 27, 2008 4:49 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Can someone confirm the following about
"scratch" tapes or "scratch pools" ?

> One other related question. When volumes in a production media pool
become 
> recyclable, they will stay in that pool unless they are relabeled into

> another. What i would like is not only a dedicated scratch pool, but
when 
> tapes become expired it would be nice for them to be automatically
labeled 
> into the scratch pool again, ready for the next request from whatever 
> group source backup.

I don't see any advantage if that was to happen, in fact there is one 
disadvantage. By relabelling recycled volumes into a scratch pool you 
would lose all chances of restoring data from these tapes. OK I know 
they are recyclable and you are not supposed to want to restore from 
them, but the fact remains that by scanning them or restoring an earlier

index it IS possible to recover data from them, and some would say this 
is a good thing in certain circumstances.

In any case, this is not something NetWorker is designed to do, and 
doing this would be an extra unecessary tape operation.

> It seems to me that in order to be able to do that you would have to
set 
> recycled from pools in the group sourced media pool, so that every
pool 
> could grab volumes from any other pool (as long as the scratch source
pool 
> has recycled to pools yes).

It is usually a good idea to set most pools to recycle to and from other

pools. Then if you need to know how many tapes are available for backups

you can just do a simple mminfo query to count how many recyclable tapes

are in your jukebox. For this purpose there is no need for a dedicated 
scratch pool.

> This seems very messy and a candidate for trouble, and an ugly way to
do 
> something the product should automatically do by default. I see a
possible 
> workaround to run a scheduled script that finds recyclable volumes in 
> production media pools and relabel to the designated scratch pool.

I don't see this as at all messy or ugly, and don't see how it would 
cause trouble. The product has behaved like this for many years and I 
don't know of any problems caused by this. Running a script to do this 
would be a little pointless IMHO and just causes unnecessary work for 
the jukebox.

> Does this make sense to anybody?

Only if they have worked with another backup product that requires you 
to work in this way.

It is possible to create the concept of a scratch pool in NetWorker, but

this is most useful for new tapes. You can create a pool called scratch,

with the "recycle to other pools" flag set, and use this for labelling 
all new tapes into. A little script to then mark all tapes in the 
scratch pool as recyclable is then useful to complete the picture. This 
is useful if you are not keen on the Auto Media Management feature (as 
in my case).

There is no other reason IMHO to use a scratch pool.

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

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