Volumes not expiring correctly when in 2 groups

[jouell]

Our database clients are defined twice, once for the file backup with 3 months retention (saves to system pool) and also for Oracle backup with 2 weeks retention (saves to oracle pool).

Problem:

The Oracle client instance uses the max retention policy for its indices when it writes to the oracle pool (I don't know why - seems like a bug), so our oracle tapes are expiring in 3 mo, not 2 weeks.


Legato says follow tech id: legato 15378 and to save our index to a separate pool.

That seems silly to spin an SDLT just for indices.

I am giving Legato a piece of my mind as we speak,
however, I know a lot of smart people hang out here.

Has anyone found/know of a solution for this?

Thanks!
-John

 

[605]

Different policies for the same client are possible from NW 6.0 and up.

Usually, customers want to sort backup data for various reasons. However, technically, sorting data is relevant if you have different retention policies for your save sets.

In general it is also a good idea to separate index and bootstrap data to a specific pool. This would speed up a disaster recovery if such would be necessary because this data for all clients reside on one or very few media.

However, to verify that your behaviour is not a bug, we need to know a bit more of your pools' setup.

 

[LGTObug]

show your pool config

 

[Serbtastic]

You also don't mention what version of Networker you are using. As 605 stated, NW v. 6X had the ability to save different savesets with different browse/retention policies. If you are using NW 5.x, then all savesets will have the same B&R policy (the most conservative one - in your case 3 months).

Also, I agree that a lot of smart people hang out here, including a lot of smart Legato Technical Support people, so 'giving Legato a piece of your mind' will certainly not encourage them to help you in the future.

 

[jouell]

Folks,

Let me say a few things:

I greatly appreciate any and all input. I mean no offense to any vendor, instructor, or user. Apologies to those whom I have.

However, I am a customer and demand quality software. I find workarounds unacceptable. In a business critical situation, you cant't afford to be silent. Its unfortunate but unless you speak up you are passed over. Having said that I may need to learn to relax just a bit =).


Getting back to the fun stuff! :

For us having one tape with a capacity of 320GB holding indices (/var/nsr/index is only 4GB) jusy seems inefficient at best. Not to mention we are at %50 capacity since we need to mount a tape doing only indices, when it could be doing NT/oracle/unix backups. (2 tape drives in the jukebox)



So my ultimate concern is simple:

Our legato 7.0 networker server (backing up oracle 9.2 w/ nmo 3.5 on unix tru64 5.1b, with legato 7.0 and 6.13 clients) should be expiring its tapes at a 2 week interval and it is not.


I would be glad to list any/all info needed, I am not a legato networker expert, but am open to suggestions, so thanks for your time!

-john

 

[605]

Please remember that up to now we did not even knew the minimal requirement that you need to support your intention - the NW version.

Looks like you overwrite the index information every time. If this is really the case, 4 GB on a 300GB tape is a waste of space if you only want to use it for only once instance of index backups.

Now, without knowing your configuration, the only possibility to find what is causing the problem is to find out which save set(s) on a media belonging to the oracle pool expires when.

To investigate, run the command
mminfo -q "pool=oracle" -r "volume, ssretent, name"
and check the output.

 

[jouell]

The backup pieces are expiring on time, their indices are not:

EX:

volume retent name
GCK550 01/23/04 index:erpdbdev1
GCK550 01/23/04 index:erpdb2
GCK550 01/24/04 index:erpdb2
GCK550 01/29/04 index:erpdb2
GCK550 01/23/04 index:erpdbrac2
GCK550 01/24/04 index:erpdbrac2
GCK550 01/22/04 index:erpdb4
GCK550 01/23/04 index:erpdb4
GCK550 01/22/04 index:erpdbrac1
GCK550 01/23/04 index:erpdbrac1
GCK550 01/26/04 index:erpdbrac1
GCK550 01/28/04 index:erpdbrac1
GCK550 01/29/04 index:erpdbrac1
GCK550 11/06/03 finoid_arch_1526_1_508122959
GCK550 11/06/03 finoid_arch_1527_1_508122959
GCK550 11/07/03 finoid_arch_1533_1_508211130
GCK550 11/07/03 finoid_arch_1534_1_508211130
GCK550 11/09/03 finoid_arch_1547_1_508381413

As there is only one in per phys. client they're saying use a new pool.

Should i use DNS aliases to circumvent this? Will that even work?

Let me know if you have questions.

thanks!
-john

 

[605]

John,

as a tape can only be completely overwritten, ALL save sets must have expired (must have passed their retention period. Only 1 save set with a longer retention policy is enough to cause these problems. The reason for that is obvious: You mix data from your oracle server (a NW client) and your backup server (which is ANOTHER NW client). Both obviously have different retention policies defined.

To solve your problem, you have the choice:
- You use the same retention policies for all save sets that can be stored on that media.
- You may reduce the retention period for your NW server's client resource (if you are allowed, as indexes for other clients may be kept longer).
- You may isolate these save sets on another peace of media (not what you want).
- You may in fact keep the data on another media, for instance a smaller tape drive, where you swap the media manually.
- You may even use a hard drive for your index data. In this case you need such license as well.
- You may use mminfo/nsrmm to change the retention date for the specific save sets (can even be done after the backup has taen place). The question again is whether you are allowed as the result is the same as option #2.
- Or you may simply manually overwrite the media by manually labeling it in advance.

 

[julianbarnett]

We have the same sort of setup and problem - fixed using a script run from cron every day before the backups are run. As long as all your Oracle pool tapes expire after 2 weeks this should work. Comment out the nsrmm line to test that the right tapes are getting logged as eligible for recycling before running this in anger. We found that only certain tapes were not expiring correctly hence the egrep for 'E', already recycled tapes

#!/usr/bin/ksh -p
#
# Use to recycle tapes last written to more than $1 weeks ago - (default 2) from $2 pool - (default oracle)
#
WEEKS_AGO=${1:-2}
POOL=$(2:-"oracle&quot
TODAY=`date +%a`
LOGFILE=/nsr/logs/recycled-tapes.$TODAY
>$LOGFILE
#
# Produce list of eligable tapes in $POOL pool not already recycled and over $WEEKS_AGO weeks since last written
#
for VOLUME in `mminfo -aq &quot;volaccess<=${WEEKS_AGO} weeks ago,pool=${POOL}&quot; -r &quot;state,volume&quot; 2>/dev/null | egrep -v '^E|volume' | awk '{ print $1 }'`
do
DATE_LAST_ACCESSED=`mminfo -a -r &quot;volaccess&quot; $VOLUME`
TAPE_POOL=`mminfo -a -r &quot;pool&quot; $VOLUME`
echo &quot;Recycling $VOLUME last accessed on $DATE_LAST_ACCESSED pool $TAPE_POOL&quot; >>$LOGFILE
nsrmm -y -o recyclable $VOLUME >>$LOGFILE 2>&1
done

 

[nandfred]

Its an old 'bug' in networker 6.x.
I belive your server is not part of the oracle group, and therefor the indexes get the longer retention time of the server in the other group.

If you create another instance of your server, put that in the oracle group, and give it the same retetion policy as the oracle clients everything should expire at the same time. Also create an all skip schedule and use that on the server in the oracle pool.

Should solve your problem.

 

[jouell]

Thanks for all the replies!

I think this would work really well:

Changing the browse/ret policy of the client resource of the networker server to 2 weeks.

(me thinking out loud):

Then the indices and data on all oracle tapes expires in 2 weeks. (Awesome)

Now , the indices on all system tapes expires in 2 weeks as well, but the data expires in 3 months. The indices would actually be available for 3 mos on the system tapes since the volume would not expire until 3 months comes around.

(and we could recover that w/some utils)

Any downsides I may be missing?


Thanks!
-john

 

[rmtsmith]

Another solution would be to use the 'no index save' option on your oracle group. Then no server indices would be written to that tape pool.

 

[jouell]

OK dont i want indexes though?

 

[605]

You bet! - But you can save them separately to a special pool:
- create a new group
- make ALL clients members of this group
- Create the newpool "Indexes"
As selection criteria ONLY set the save set attribute to
index
bootstrap
- Label media for that pool
- Start the group from the command line:
savegrp -l level -G groupname -O

This will only save the indexes and the bootstrap for all members of that group.