In researching some answers to the original post I was reminded that
most Oracle backups use an infinite retention level with RMAN managing
the actual retention level. Does this ring any bells for anyone else, or
am I getting senile in my old age.
Regards,
Patrick Whelan
NetBackup Specialist
Architect & Engineering
-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of
Mark.Donaldson AT cexp DOT com
Sent: 19 January 2006 17:09
To: austin.murphy AT gmail DOT com; veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] Database backup scheduling with different
retentions
I can answer for Oracle - I assume that the MSSQL would be similar.
When your RMAN script runs, it sends data to the Netbackup Oracle agent.
The agent, in turn, sends the data onto a Netbackup media server, to a
particular policy & schedule. In the RMAN script, you can specify the
NB_ORA_POLICY and NB_ORA_SCHEDULE variables. These variables select
which
Netbackup (Oracle-type) policy & schedule are used to recieve the data.
Netbackup's retention of the data, therefore, is the retention period
set on
these "application backup" schedules. At the end of the retention
period,
therefore, NB will discard the images. If you want three different
retentions, create three different schedules (it can be in the same
policy).
Have RMAN set the schedule variable appropriate to the type of retention
you
wish to select.
This has nothing to do with retention periods set by RMAN within the
RMAN
scripts. RMAN can say "keep this for a year" and what it really is
doing is
keeping its info on those data blocks for a year. If it tries to
restore
an old image, it's going to request specific backup pieces from
Netbackup.
If NB's scheduled retention is less than RMAN's retention, there's a
risk
that RMAN will get a failure from NB - the images will no longer be in
NB's
image set.
There's two ways to deal with this:
1. Set NB's retention to be the same (or more) than RMAN's retention
periods.
2. Frequently sync RMAN's catalog against NB's catalog so RMAN stays
current
with NB's actual retained data. This is the most accurate but more
complex.
Here's a technote to get you started:
http://seer.support.veritas.com/docs/251686.htm
HTH - M
-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of Austin
Murphy
Sent: Thursday, January 19, 2006 8:23 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Database backup scheduling with different
retentions
Does anyone have any insight on how to do scheduled
weekly/monthly/yearly backups (with commensurate retention periods) of
an MSSQL or Oracle database with Netbackup?
I am running 5.1 MP3 on Solaris 9 and just found out that the database
policy schedules don't work the same way as the file policy schedules.
It has been pointed out to me that I could setup 3 Policies for
weekly/monthly/yearly backups, but this won't stop the weekly when a
monthly runs. Nor will the monthly (or weekly) be suspended when the
yearly is run.
If anyone has any ideas I'd be grateful to hear them. Thanks.
Austin Murphy
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
*************************************************************************************
The message is intended for the named addressee only and may not be disclosed
to or used by anyone else, nor may it be copied in any way.
The contents of this message and its attachments are confidential and may also
be subject to legal privilege. If you are not the named addressee and/or have
received this message in error, please advise us by e-mailing security AT colt
DOT net and delete the message and any attachments without retaining any
copies.
Internet communications are not secure and COLT does not accept responsibility
for this message, its contents nor responsibility for any viruses.
No contracts can be created or varied on behalf of COLT Telecommunications, its
subsidiaries or affiliates ("COLT") and any other party by email Communications
unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate
potential viruses and unsolicited promotional emails. For more information
refer to www.colt.net or contact us on +44(0)20 7390 3900.
|
