You could create a schedule like Skip-Skip-Skip-Skip-Skip-Skip-Skip
for that container's client and launching the index only backup 
forcing the backup level to use...

eg "savegrp -O -l full MyIndexGroup"

or forcing group schedule

eg "savegrp -O -C <schedule> MyIndexGroup"

HTH

Thierry


Kind regards - Bien cordialement - Vriendelijke groeten,

Thierry FAIDHERBE
Backup/Storage & System Management

LE FOREM
Département des Systèmes d'Information
Direction Infrastructure

Boulevard Tirou, 104  Tel:    +32 (0)71/206730
B-6000 CHARLEROI      Mobile: +32 (477)/995319
                      Fax:    +32 (0)71/206199 
BELGIUM               Mail : Thierry.faidherbe<at>forem.be


-----Message d'origine-----
De : EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] De 
la
part de Paul Robertson
Envoyé : vendredi 4 novembre 2011 02:55
À : NETWORKER AT LISTSERV.TEMPLE DOT EDU
Objet : [Networker] Index backups for clients with scheduled backup set to
disabled

We use NMDA 1.1, Networker 7.6.X, and crontabs to backup our Oracle
database instances via RMAN running in Solaris containers/zones. Since
we choose to backup the zone's non-oracle filesystem data (e.g. /var)
via the globalzone, we've set "Scheduled Backup" to disabled for the
container's Networker client resource.

Everything works well enough, except for the minor annoyance that we
have to remember that the file index for the container is associated
with the global zone and paths are relative to the global zone. Of
course, the Oracle RMAN/NMDA backup indexes are associated with the
Solaris container. In general, this approach works well enough, in
that we restore the zone's filesystem data from the global zone, and
the RMAN/NMDA database information is restored from the container.

Unfortunately, setting the container's "scheduled backup" resource to
"disabled" has the undesired side effect that the daily index-only
backup via "savegrp -O" doesn't include the file index information for
the container. In the event that we ever have to recover our Networker
server in a disaster situation, our index tapes would be missing the
container's file index info.

I suppose we could work around this by enabling scheduled backups for
the database container as well, and setting the "save set" resource
parameter to a small folder like "/etc". This should ensure that the
Solaris container's file index information (which now includes both
the useless /etc entries as well as the critical RMAN/NMDA file
index). However, I would like to think that there is a more elegant
solution that I'm missing.

Any advice is appreciated.

Cheers,

Paul

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