Showing results for 
Search instead for 
Did you mean: 

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)
6 Replies

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.


Re: NetBackup Copilot

That's a good detailed explanation. Thanks for it.

However both the options seems be costly. We are un-necessarily reserving disk space (as NFS share) to mount on DB server. Assuming an environment which has appliances , this is going to be a double investment (I don't think MSDP works for NFS share it only works when the data is copied/backed up from that share) as we need to reserve space for NFS share.

Also calculating the size of NFS share is a challenge. Let's say you have 20TB DB , upfront you need to keep aside 20TB of share from appliance plus incremental/archive logs size .

What's your view on above ?


Re: NetBackup Copilot

From a disk space perspective, the amount of NFS staorage required from the appliance is dependant on the size of the DB and the change rate of the DB for the number of days the backup resides on the NFS share. 

For the incremental merge scenario, this implies, the size of the full database dump, plus enough space to accommodate an incremental dump together with enough space to manage the maximum number of snapshots desired to be kept online. 

For the other method, the same calculations are required - this time it is usually the DBA that determines how long the backup sets lives on the NFS share. 

The NFS share is not generally used to backup archive logs to - these would more typically be sent direct to MSDP or other backup storage.

Re: NetBackup Copilot

So in short we will defenitely reserve some space on NetBackup appliances for co-pilot to present as NFS shares ?

I feel bit unfomforble to waste space on a dedup appliance for NFS shares..

Re: NetBackup Copilot


Work with your local Veritas partner. 
They have access to the latest Appliance calculator that caters for Copilot sizing apart from dedup sizing. 

Re: NetBackup Copilot

Hi Marianne,

Thanks for your response. Yes I'm trying to engage them. But we want to implement it in an existing environment and wondering if I need to buy more appliances to serve the purpose.

Is anyone already tested and using co-pilot ?