SearchFAQMemberlist Log in
Reply to topic Page 1 of 1
Index backups for clients with scheduled backup set to disab
Author Message
Post Index backups for clients with scheduled backup set to disab 
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


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Post Index backups for clients with scheduled backup set to disab 
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.EDU] De la
part de Paul Robertson
Envoyé : vendredi 4 novembre 2011 02:55
À : NETWORKER < at > LISTSERV.TEMPLE.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


"signoff networker" in the body of the email. Please write to
networker-request < at > listserv.temple.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


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
  


Magic SEO URL for phpBB