Commulative-incremental backup do not start

[Alex_Zn]

Hi!

I have a problem with automatic start of commulative-ibcremental backup.

I use commulative-incremental backup for Oracle archive log backup. Because there is no special backup type exists for this kind of task, i use "automatic commulative-incremental backup type. Problems with automatic start appeared when i tried to connect my first Oracle system, if i tried to manually run a script from client, or do manual backup from NetBackup, all works fine. But when time comes to run, it do not start, no error messages, no writes in activity monitor, absolutely nothing. Then after, some time, Commulative-incremental begin to work, seams it happens when full backup time comes. Problem in not with one client it exists and for an others.

[Marianne]

NBU version? OS on Oracle client? Please show us your policy. On Master, run: bppllist -U Cummulative backups for archive logs are not really applicable. Rather choose automatic full. Policy output will tell us if you are using Frequency or Calendar based backups and what your backup windows are. PS: Only noticed the 7.5 tag after I have posted.....

[Alex_Zn]

>NBU version?

7.5
>OS on Oracle client?

Two AIX 6.1 and one Linux 6.x

>Please show us your policy. On Master, run:

>bppllist -U

>Policy output will tell us if you are using Frequency or Calendar based backups and what your backup >windows are.

I use period based schedule, period - every hour,  with 24 hour window. This rule works fine but not all time :) Do i still need to show bppllist -U ?

>Cummulative backups for archive logs are not really applicable. Rather choose automatic full.

Automatic full i used for Full backups, but this is huge amount of data, i have RPO for this system 1 hour, so i should backup it every hour. It is impossible to create full backup every hour.

I use my own RMAN script, it process NB_* variables to determin type of backup which was called from NetBackup, if type Automatic Commulative-incremental it just perform Archive log backup. Is there some difference for NetBackup what type of backup it calls ? 

[Marianne]

Sorry, without details it is difficult to even guess. I also battle to understand the reasoning behind incrementals for archive logs. They are deleted after each backup. So, they are all new every time arch log backup runs.

[Alex_Zn]

I `ll try to explain.

For hot oracle backup i may choose one of next mechanisms:

1. Backup full+archive logs (period=1 day) and then differential incrementals+archive logs (period=1 hour). In such case i need to backup only those archive log files that was created in time of backup.

2. Backup full+archive (period=1 day) logs and then archive logs (period=1 hour) seperately, In such case i refuse to use differential backups instead i use archive log backups. After backup, archive logs crear on client.

Costumer`s DBA prefers second method because it  more reliable. In some versions of oracle there was an issue with differential incremental backups which was leeded to inconsistent backup. There is no sens to make differential backup if i could make archive log backup, backup time the same, recovery time the same.

Next, i need to realease what costumer wants, so most appropriate variant for me was to use "Cummulative incremental" type of schedule to run standalone archive log backup.

C:\Users\admvksenzov>bppllist mypolicy_name -U
------------------------------------------------------------

Policy Name:       mypolicy_name

  Policy Type:         Oracle
  Active:              yes
  Effective date:      06/08/2012 12:10:00
  Block Incremental:   no
  Mult. Data Streams:  no
  Client Encrypt:      no
  Checkpoint:          no
  Policy Priority:     0
  Max Jobs/Policy:     Unlimited
  Disaster Recovery:   0
  Collect BMR info:    no
  Residence:           Oracle
  Volume Pool:         NetBackup
  Server Group:        *ANY*
  Keyword:             (none specified)
  Data Classification:       -
  Residence is Storage Lifecycle Policy:    yes
  Application Discovery:      no
  Discovery Lifetime:      28800 seconds
ASC Application and attributes: (none defined)

  Granular Restore Info:  no
  Ignore Client Direct:  yes
Enable Metadata Indexing:  no
Index server name:  NULL
  Use Accelerator:  no
  HW/OS/Client:  RS6000        AIX53         myhost_name

  Include:  /home/oracle/database_backup.sh

  Schedule:              OracleFullBackup
    Type:                Automatic Full Backup
    Frequency:           every 1 day
    Maximum MPX:         1
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     0 (1 week)
    Number Copies:       1
    Fail on Error:       0
    Residence:           (specific storage unit not required)
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          эхф¦ы      22:00:00  -->  яюэхф¦ыюъ  02:00:00
          яюэхф¦ыюъ  22:00:00  -->  т¦тЄюЁюъ   02:00:00
          т¦тЄюЁюъ   22:00:00  -->  ёхЁхфр     02:00:00
          ёхЁхфр     22:00:00  -->  ўхЄтхЁ     02:00:00
          ўхЄтхЁ     22:00:00  -->  я' ЄэшЎ    02:00:00
          я' ЄэшЎ    22:00:00  -->  ёєсюЄр     02:00:00
          ёєсюЄр     22:00:00  -->  эхф¦ы      02:00:00

  Schedule:              OracleArchlogBackup
    Type:                Cumulative Incremental Backup
    Frequency:           every 1 hour
    Maximum MPX:         1
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     0 (1 week)
    Number Copies:       1
    Fail on Error:       0
    Residence:           (specific storage unit not required)
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          эхф¦ы      00:00:00  -->  эхф¦ы      24:00:00
          яюэхф¦ыюъ  00:00:00  -->  яюэхф¦ыюъ  24:00:00
          т¦тЄюЁюъ   00:00:00  -->  т¦тЄюЁюъ   24:00:00
          ёхЁхфр     00:00:00  -->  ёхЁхфр     24:00:00
          ўхЄтхЁ     00:00:00  -->  ўхЄтхЁ     24:00:00
          я' ЄэшЎ    00:00:00  -->  я' ЄэшЎ    24:00:00
          ёєсюЄр     00:00:00  -->  ёєсюЄр     24:00:00

  Schedule:              Default-Application-Backup
    Type:                Application Backup
    Maximum MPX:         1
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     0 (1 week)
    Number Copies:       1
    Fail on Error:       0
    Residence:           (specific storage unit not required)
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          эхф¦ы      00:00:00  -->  эхф¦ы      24:00:00
          яюэхф¦ыюъ  00:00:00  -->  яюэхф¦ыюъ  24:00:00
          т¦тЄюЁюъ   00:00:00  -->  т¦тЄюЁюъ   24:00:00
          ёхЁхфр     00:00:00  -->  ёхЁхфр     24:00:00
          ўхЄтхЁ     00:00:00  -->  ўхЄтхЁ     24:00:00
          я' ЄэшЎ    00:00:00  -->  я' ЄэшЎ    24:00:00
          ёєсюЄр     00:00:00  -->  ёєсюЄр     24:00:00

[Marianne]

Thanks - we can see that Frequency Based schedule is in place with a frequency of every one hour and that backup window is open 24x7.
So, according to yesterday's post:
This rule works fine but not all time

How often is it working fine?
When do you see it NOT working?
By any chance after one of the hourly backups have failed?
I have seen this behaviour after a failure when NBU for some reason applies the 'number of tries per ## hours' in Global Attributes. The default is 2 tries every 12 hours.
If this your problem as well, you may want to reduce the frequency to something like 1 every 2 hours.
The other option is to run a manual backup after a failure to kick-start the hourly schedule again.

You can use Automatic Full for Archive Log backups. As per my previous post, Arch logs are backed up in full and deleted upon successful backup. Any type of incremental backup does make sense with this in mind.
We normally configure a separate policy for our customers' hourly Arch Log backups.
The DBA's then hard-code the policy name in the script used for Arch Log backups.
Please bear in mind that the /home/oracle/database_backup.sh script will be used for even the hourly backups. Best to have a separate policy and script.

[mph999]

You could also look in nbpemreq -subsystems 1 screen

You have to run this before the backup is due to start (so might take repeated goes ) ...

This will show for each client/ policy pair ,  when NBU plans, and what schedule, to run for a backup, and why ...

Martin

[Alex_Zn]

After some testing with failed full backups, i may declare next:

Incremental backups (both) are connected with Full backup, if full failed with its schedule, commulative will not be quied while successfull full will not finished. I have checked this on "Standard" policy type, i have pointed selection list to folder on client:

Commulative period 1 hour, Full period 2 hours

1. I run manual backup of folder - successful.

2. I have moved folder to folder.1 on client.

3. Automatic commulative run according to its schedule - failed

4. Full backup run according to schedule - failed.

5. Full backup run according to schedule - failed.

6. Full backup run according to schedule - failed.

7. I have moved folder.1 to folder on client

8. Full backup run according to schedule - succesfull

9. Commulative backup run according to schedule - succesfull

10. Last two repeat till now.

As you see no attempts to run commulative backup was made when full have been failing.