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
|