Autobackup is an RMAN setting. We use autobackup
and had recovered the controlfile for the attempted restore I talked about
earlier. However, because RMAN had already expired the required images
from its own catalog, we were unable to recover the data, even with backup
images still residing in the Netbackup catalog.
Mark Glazerman
Desk: 314-889-8282
Cell: 618-520-3401
P please don't
print this e-mail unless you really need to
Thanks guys.
Is autobackup a setting in RMAN or in NBU?
As long as you have autobackup enabled, you shouldn’t
need the rman repository. If netbackup has the images in the catalog, restore
the control file from autobackup, which has the rman pieces info and will poll
netbackup for the images associated with them.
Jeff,
I can only really comment on your last question about
using expired RMAN images for restores if they are not expired in
NetBackup. We had a similar issue a few weeks back where Netbackup could
still see images in its catalog of oracle backups (which initiate a RMAN backup
via the oracle_backup.sh script) but RMAN had already expired them inside its
own catalog. These files were not recoverable by RMAN. We had the
DBA’s set their retention inside RMAN to match the retention specified inside
NBU so that we don’t see this mis-match again.
Ultimately, RMAN controls the expiration of the images
inside its catalog meaning that regardless of the expiration you set for oracle
backups inside NBU, RMAN will keep or expire those images, regardless of what
Netbackup is trying to tell it. I don’t know how you’d configure RMAN to
handle your vaulting needs. Would setting the expiration of these images
in RMAN to the longest required length of time (4 months for example) mean that
the vaulted images would still be good for the max time they’d need to be held
on either the Data Domain or tape ? The Netbackup catalog doesn’t need to
know about the RMAN images for them to still be recoverable by RMAN so you
could set a different, shorter expiration inside NBU although this would still
leave you with different retentions in the two different catalogs
FYI The solaris client we were trying to restore these RMAN images to is
running 6.5.4 with a 7.0 master and media server.
Mark Glazerman
Desk: 314-889-8282
Cell: 618-520-3401
P please don't
print this e-mail unless you really need to
My DBAs are
starting to question me about an RMAN crosscheck they are running.
Essentially
I gather that when they ran it the crosscheck seemed to report even backups run
in the last 2 days as expired.
On checking
the Data Domain unit I can see the images are still there and on running
NetBackup commands I see these are NOT expired from NBU’s perspective.
On doing a
search I did find a document at Symantec that talked about RMAN expirations but
it only went up through 6.0 so I’m not sure if it is still valid for 6.5.
It says essentially that on the NBU side we should set very long retentions
(e.g. INFINITY) for all RMAN backup policies then let RMAN keep track of
retentions itself. The downside I see to this is we do vaulting of
the images on data domain to tape – we set retention on data domain to 1 month
then the vault copies get longer retentions (e.g. 3 months for a daily
backup). How would we get RMAN to set and keep track of such
retention differences?
The DBAs
have opened a TAR with Oracle to see why the crosscheck is reporting the images
as expired but I suspect from the NBU document that the answer will be
something like “it is expired so far as RMAN is concerned”. This
also begs the question as to whether RMAN could be used to restore the backups
even if they aren’t expired so far as NBU is concerned. Does anyone know
the answer to that?
Proud
partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or
attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
----------------------------------
This message is private and confidential. If you have received it
in error, please notify the sender and remove it from your system.