Networker

[Networker] Confusion over recycled save sets and tapes - need help

2011-06-29 18:36:32
Subject: [Networker] Confusion over recycled save sets and tapes - need help
From: bingo <networker-forum AT BACKUPCENTRAL DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 29 Jun 2011 15:34:41 -0700
I'm confused over the possible advantages/disadvantages of marking a
tape manual recycle versus notrecyclable ('nsrmm -o notrecyclable
volume'). There's just too many permutations to test all this myself, so
I have several questions below that will help me to better understand this.

First, from what I do understand, when a save set reaches its retention
period, the sumflags, ssflags, and clflags value will change to include
an 'E' to indicate that the save set is eligible to be recycled (e.g.
cE vrEF E instead of, say, cr vrF). Once all the save sets on the tape
have expired then the tape is indicated as recyclable. If said tape is
loaded into the tape library, and it's not physically write protected,
then NW could overwrite the volume if it needed a tape, and there were
no other available volumes. Even setting the tape to read-only (software
option) will not prevent this behavior. This is defacto with NetWorker.
That right?
>>>>> Correct. 

HOWEVER, if the tape is set to manual recycle then NW will never recycle
it. I assume that this does not change any of the mminfo attributes
(e.g. ssretent, clretent, etc.) of the save sets but instead sets some
flag (mminfo: manual) in the media database to indicate that the given
tape cannot be recycled, correct?
>>>>> Yes, sir.

BUT, if you set a tape to manual recycle, and at least one save set has
not reached its retention period then that save set will still expire at
some point. In other words, the 'manual' option does not prevent save
sets from expiring, so if someone later changed the tape to 'notmanual',
and all the save sets had already expired, and it was loaded into the
library, then NW could overwrite it, yes?
>>>>> Also right.


Here are some questions:

1. What if you instead marked one save set on the tape as notrecyclable.
If even just one save set is set like this then the tape cannot be made
recyclable, right? Wouldn't this accomplish the same thing as the manual
option? 
>>>>> De facto, yes. That's why you want to filter save sets with different 
>>>>> retention period to different media pools.
Otherwise, one save set with a longer RP will block the whole tape.


Note: Here I'm assuming that the save set has not expired. If it has
then I guess you need to first use nsrmm -e to change its clone
retention time, and then you can make it notrecyclable which would then
reset the ssretent to the same. 
>>>>> Not sure about that. 'notrecyclable' will change the ss/vol status to 
>>>>> recoverable. However, it can not change the retention date (only for a 
>>>>> save set) as this command did not supply one.


2. What if you set the clone retention time of one of the save sets to
'forever' or some date far in the future. Would this likewise result in
basically the same result?
>>>>> The consequence is that the tape will never be relabeled automatically. 
>>>>> This is an archiving approach.
Setting the retention date is a save set related feature which can not be 
applied to the tape. The retention time for the tape is represented by the 
retention date of the 'latest' save set.


3. What's the better option? To make one save set notrecyclable or
instead just assign it a clone retention time of 'forever'?
>>>>> Set the retention time to 'forever'. This is a proactive step as the tape 
>>>>> will never expire. Once again, notrecyclable only makes sense for ss/vols 
>>>>> which have already expired.


4. It seems like the safest way to prevent a volume from being
overwritten would be to:
a. change at least one save set to have a clone retention time of
'forever' or set that save set to notrecylable
>>>>> NO

b. change the tape to manual
>>>>> NO

c. write protect the tape
>>>>> This is the safest way. a) and b) can still be executed (accidentally).
As you already block the execution on the hardware level, you may type any 
command - but writes will be prevented.

d. lock it away with a big ugly warning.
That sound right, in a paranoid way?
>>>>> That's why you still want to separate drive and media


4. Can a tape marked as either manual recycle or notrecyclable be
removed from the volumes listing?
>>>>> It can be removed at any time despite its status. Just run 'nsrmm -d 
>>>>> volume'


5. Can a tape be made both nonrecyclable and manual?
>>>>> Sure.


6. Can a save set that is made notrecyclable be deleted from the media
database (nsrmm -d)?
>>>>> Sure. 'nsrmm -d -S ssid[/cloneid]'


7. Once a volume is made manual recycle will NW also make it
read-only(R)? Does that happen automatically?
>>>>> No, as you can set it to 'manual' already when you label it. However, an 
>>>>> empty media with read-only status does not really make sense.

Unfortunately, NW uses two parameters (wrong): 'write protected' & 'read only'. 
'Write protected' is a software flag you may set - it does NOT represent the 
status of the media's write protect notch.
'Read only' is the logical consequence - it is set automatically whenever a 
media has been filled (no more space to write) or it will be set to 'full' (a 
precaution, if NW cannot recover from a write error before it has reached the 
'max. consecutive errors' (default=20)) .

>>>>> NW has a lot of different commands/options that will finally have the 
>>>>> same effect.

+----------------------------------------------------------------------
|This was sent by carsten_reinfeld AT avus-cr DOT de via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------

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

<Prev in Thread] Current Thread [Next in Thread>