NetBackup Copilot

I'm looking at implementing Copilot for Oracle backups, but I'm confused about which method to then use to backup the Oracle DB's...

Chapter 5 of the copilot admin guide states that there are 2 options available for OIP configuration either database backup share using database dump backups


whole database - datafile copy share using Oracle accelerator backups.

So the questions are what are the pro's and con's of each method and what are the criteria for choosing one method over the other?

Tags (1)
1 Reply

Re: NetBackup Copilot

Hi, some info to help you choose.

Whole Database - Datafile Copy Share (Oracle Accelerator)

  • NetBackup controls the backup. The Oracle DBA does not have to do anything. Except maybe when it comes restore time.
  • The term "Oracle Accelerator" is just a fancy way of Veritas saying they're using RMAN's Incremental Merge (aka Incremental Forever) db image copy commands, which is entirely an Oracle RMAN feature.
  • When a job runs, NetBackup tells RMAN to create an Image Copy of its entire DB inside the share if there is no previous Image Copy. But if there already is one, then do INCREMENTAL LEVEL 1 updates to that Image Copy.
  • From the perspective of RMAN's backup records (either from ControlFile or Recovery Catalog), there is only ONE Image Copy of the entire DB, and it is located in the share.
  • Each time this backup job is run, all RMAN does is update this same Image Copy with an Incremental, similar to a "Synthethic Full". You're not creating a new Image Copy of the DB each time, you're just updating the same Image Copy with the latest updates.
  • This setup is great for backing up large DBs. All backup jobs from now on will be very fast, because you are effectively doing "Incremental Forever". No more waiting hours for a full backup job to complete, because there will be no more full backup traffic from Oracle to NetBackup, EXCEPT for the first backup.
  • But then, that Image Copy inside the share IS practically a full backup that is constantly updated each day (Assuming you run this job daily).
  • During a restore, the benefit of restoring from 'Full+ArchLog only' compared to restoring from 'Full+Inc+Inc+Inc...+ArchLog' is that the former restore will complete faster because there are less items in the restore-chain, and therefore the RTO is lower/faster. (I mentioned Archived Logs because you're also supposed to do Archived Log backups regularly together with the Incremental Forever "Full", and during restores you're supposed to restore them together.)
  • (Note: In the world of RMAN, 'Image Copy' and 'Backup Sets' are different. But their restore commands are practically the same. So, from a restore script's perspective, in-most-cases it makes no difference whether you're restoring a DB from an 'Image Copy' or a 'Backup Set'. Refer to RMAN guides for all the differences between them.)
  • If we just leave everything like that, sure you now have fast, daily full backups, but there is still one problem: You cannot restore older data. Like, what if there is a need to restore the DB as it was 2 months ago? Well, you can't (yet), because that single Image Copy is constantly updated everyday. You can only ever restore the latest backup.
  • That is why there is a second part to this method. Everytime right after the "Incremental Forever" part finishes updating the Image Copy in the share, NetBackup creates a Proxy Copy of this Image Copy and put it in a SLP/Storage Unit of your choice (MSDP, AIR, Tapes, etc.). So now, if you want to restore from the lastest backup, you can restore from the Image Copy, and if you want to restore from other older backups, you can restore from the older Proxy Copies. (Note: Proxy Copies are pretty much just Image Copies created and managed by 3rd party backup solutions like NetBackup. Refer to RMAN guides for more info.).
  • The Proxy Copy records are updated to the RMAN backup records, so RMAN knows about their existence and can therefore use them during restores.
  • Pro: No need for DBA to worry about backup storage (E.g., the FRA), because backups are stored in a NetBackup provided share.
  • Pro: Forever Incremental is fast, forever, except for the first actual full backup.
  • Pro: Restores are fast because of a short restore chain. I.e., 'Full+ArchLog' instead of Full+Inc+Inc+Inc...+ArchLog'.
  • Con: For disk storage, since each Proxy Copy backup is practically a Full. It will waste a lot of storage space. Not too bad if you use deduplication disk storage (E.g., MSDP) and the dedup ratio is high.
  • Con: For tape storage, everytime you SLP duplicate to tape you are duplicating a full. This can be a major problem for large DBs and for places that require daily duplicate-to-tape jobs.


Database Backup Shares (Dump and Sweep):

  • NetBackup does not manage what and when RMAN backups are placed in the share. The DBA does.
  • To elaboarte, when a job runs, NetBackup does not tell RMAN to create a new Backup Set and put it inside the share.
  • The only thing the job does is to look inside the share, if it sees Backup Sets inside the share (that the DBA created using RMAN commands, we don't need to know when, and how frequent he/she does this), then depending on the schedule type, it will:
    • Full Schedule: Create an additional Copy of all Backup Sets found inside the share.
    • Diff/Cumu Incremental Schedule: Create an additional Copy for Backup Sets that have not already had their additional Copy created.
  • (Note: In the world of RMAN, A Backup Set can have one or more Copies. When you run a new backup, typically a new Backup Set is created with only one Copy. If you backup this Backup Set, you are not creating a new Backup Set, instead, a Copy#2 is created for this Backup Set. Refer to RMAN guides for more info.)
  • What you do with this "Backup of Backup Set" (aka Copy#2 of each Backup Set) depends on your SLPs/Storage Units like before (MSDP, AIR, Tapes, etc.).
  • The additional Backup Set Copy records are updated to the RMAN backup records, so RMAN knows about their existence and can therefore use them during restores.
  • If you are worried that the DBA does not ever delete older Copy#1s from your share to free up disk space, there is an option in the OIP policy that can basically auto delete all Copy#1s of Backup Sets once the Copy#2s are created. Sadly, the option is named "Delete protected backup sets from share after...". This is misleading because not the entire Backup Set (implying all its Copies) is delete, but only the Copy (Copy#1) of the Backup Set that is inside the share.
  • Pro: No need for DBA to worry about backup storage (E.g., the FRA), because all backup he creates will be sent to your share. Backup storage is the backup admin's problem.
  • Pro: Good for environment where the DBA wants to create and manage RMAN backups when he/she wants, how he/she wants. He/she just loves RMAN scripting.
  • Pro: In a sneaky way, and for extra safety, you are essentially creating additional Copies of the backups the DBA has already manually created. The DBA doesn't even have to know you are doing this. (But ideally you really should let him/her know!). But then, it is easy for him/her to know what is happening by RMAN>list backup; because the additional Copies of the Backup Sets will be visible. Remember: NetBackup updates RMAN's backup records (ControlFile or Recovery Catalog) on everything it does.
  • Pro: Assuming there are Incrementals, then you don't have the Tape problem as described in the 'Incremental Forever' method where everying are actually Full. The DBA should ideally do Fulls+Incrementals+ArchiveLog backups, and not just Fulls in their RMAN scripts.
  • Con: Fulls are actual Fulls send from Oracle to NetBackup, which can be slow for large DBs, slow networks and/or slow disks.
  • Con: In normal environments where RMAN creates Weekly Full, Daily Incrementals and freqent ArchLog backups, that still means you will have one slow Full backup day each week. But then again, this is the way it has always been without Copilot/Forever Incremental.
  • Con: Possibly slower restores compared to the 'Incremental Forever' method because the restore chain can be longer.
  • Con: If the DBA does not create backups (E.g., "I forgot! But I blame the backup admin!"), then there is nothing to make additional Copies of. You have a potential data-lost disaster scenario in your hands due to human errors (finger pointing to the DBA).
  • Con: If the DBA does some crazy RMAN rock star scripting gymnastics, then this whole thing might fall apart, because this NetBackup method is really for "Backup of Backup Sets". If the DBA put some weird stuff in the share, NetBackup might not be able to back them up properly. Cue shouting match.