36 Day Retention expires in 1 year

[golilang]

Greetings,

I am having trouble with a 36 day retention policy that after a backup expires in 1 year.

I have configured a "daily" policy with a retention of 36 days. I run incremental daily backups Monday through Thursday and a Friday full that all write to a daily pool. All clients that write to this pool have been configured for a browse policy of "daily" and retention policy of "daily"

However, after the backup the expiration for the tape is 1 year after the latest backup to that particular tape.

Is there a problem because the browse and retention policy are the same?

Any input is appreciated.

System Info
Sun E4500 8x400MHz
8gb memory
Solaris 7
Networker 6.1.1 build 238

 

[cyberted]

Hi goliang!

What about Index and bootstrap policies?

What else is on the tape?


cyberted

 

[golilang]

I thought that the index retention policy was driven by the browse policy. The index keeps records of files/filesystems that are backed up and in the case of my daily backup, which I want to expire after 36 days, I only want to keep a weeks worth of index data. If a restore were required past the week I would then turn to the media database.

As for the contents of the tapes I have reviewed each of the clients writing to the daily pool and each client is set with the 36 day retention. These clients belong to a daily group set to backup to the daily pool.

 

[promml]

Is the client's index-saveset also on this tape?

The index-saveset takes the NW-server policies. Review your client configuration of the NW-server. Is your server's retention policy configured to one year?

If so, backup the index savesets to a different pool or create another client resource for the index savesets.

 

[wallace88]

mminfo -av -ot -r ssbrowse,ssretent,ssflags,client,name <volume name>

will show you what savesets are on this volume. Then review this report to see if that;s what you expect.

The client index browse and retention times are determined from the backup server's client setting, since the index directory is backup from the backup server itself.

There was a problem with browse and retention policy set to be the same in NetWorker 5.x, but not in later release.

 

[golilang]

wallace88, This is a great command. Much clearer than what I using to find retention of my indexes. Promm1 pointed out that I should probably check the retention of my indexes, but I still have not been able to change it. If you have any idea how I can change it my problems should be resolved, with some questions however.

Is it possible to change retention of indexes say on a tape pool basis. What I am looking at is a daily, weekly and monthly pool. So I would need to set the index on a daily to expire in 36 days, weekly 56 weeks, etc. etc. Although not really necessary as I would still be retaining an index on the weekly and monthly pool, but something I would like to investigate.

Thanks everyone for the assist.

 

[wallace88]

Try the folloing to give the same output, but include the save set id.

mminfo -av -ot -r ssid, ssbrowse,ssretent,ssflags,client,name <volume name>

Then you can use the following to change it to be recyclable:

nsrmm -S <ssid> -o recyclable

How about putting the indexes and bootstrap on a separate pool? Create a pool with just the following characteristics:

saveset=index:*
bootstrap

Then label a tape with that pool. This will result in all indexes and bootstraps going to this pool.

 

[gdc2001]

The problem with the indexes may be down to a feature of Networker.
The Indexes should have the same retention as the savesets from that client in the group.
However if the networker server is not one of the clients in that group all the Indexes for all the clients in that group get a years retention.
The way around this is to create an instance of the server and set its SAVESET as a blank folder. Add this instance to all groups that do not contain the server already.

May help, duno.....

 

[promml]

another workaround is:
- create another client resource
- set its savesets to &quot;index&quot;
- do not add this resource to any group.

So all groups that do not contain the NWserver take this policies for its index.

In this case the completion report will not contain any information about that blank folder that gdc2001 described.