cancel
Showing results for 
Search instead for 
Did you mean: 

Force full backup to other day in backup window

ErwinVreys
Level 4

Dear All,

I have some full VM (hyper-V) backups which end on error 196 every week on the same day (Monday night). The easiest solution is to change the backup window but I have plenty of backup window over on other days.

When the clients misses there backup window the full backup is automatically taken the next day (Tuesday night).

I assumed that in the following week the full backup of these client would be taken on Tuesday night but instead it tries to take the full backup again on Monday night and fails again with error 196.

I toke a manual full backup during the day on Friday with the hope the full backup scheduled would shift to Friday night but this week the backup policy tried again to take the full backup on Monday night.

I read David Chapa's article. I understood that manual backup have influence on scheduled backups.

I did take a manual backup to influence the scheduled backup but it didn't work. Does this article still apply? I'm running Netbackup 7.6.0.4 on Windows Server 2008 R2.

How can I force the full backup of some clients taken on another day?

Regards,
Erwin

1 ACCEPTED SOLUTION

Accepted Solutions

ErwinVreys
Level 4

All,

My apologies for not answering anymore. I became ill that day and had to stay home for a couple of days to recover. Last week I had a couple days of vacation planned and we had to move our servers to a brand new datacenter.

I asked a colleague to follow the problem but got scared from NetBackup. He made a change in the name of the schedule which had quit an impact. He saw a typo error in the name of the backup schedule. The title was not consistent with all the other schedules. So he changed the name of the schedule not knowing what the impact was. Either I was not aware of the impact. Unfortunately he changed the full backup schedule so during the night NetBackup started full backups of every machine in the policy.

To get everything back to normal I started scripting bpbackup commands everyday which started full backup of particular machines at the end of the day. While doing this I actually also noticed that I was mistaken when saying that executing a full backup did not shift the schedule. I'm not familiar with NetBackup commands but I started using bpimagelist to investigate my problem. The backups were shifting but I have a few servers with almost the same name. I overlooked the name difference. I think my illness clouded my judgment together with planning the move to our new datacenter. This was not an ideal cocktail to investigate a problem.

The final conclusion is that my backup window was indeed too small that particular day. Now every backup is running normal within the planned backup window due to work I had to do after the name change.

Regards,
Erwin

View solution in original post

10 REPLIES 10

Nicolai
Moderator
Moderator
Partner    VIP   

It sound you are using calendar based backup for that VM (with re-tried enabled), if it was frequency based you are right in the observations.

Can you please check the policy - alternative do a  bppllist {policy} -U and attach the output to this thread.

ErwinVreys
Level 4

I'm using frequency based backups. I ran the bpplist command. I deleted some clients from the output and change the names of the rest of them.

------------------------------------------------------------

Policy Name:       MS_Hyper-V

  Policy Type:         Hyper-V
  Active:              yes
  Effective date:      01/07/2014 14:09:12
  File Restore Raw:    yes
  Mult. Data Streams:  no
  Client Encrypt:      no
  Checkpoint:          no
  Policy Priority:     3000
  Max Jobs/Policy:     1
  Disaster Recovery:   0
  Collect BMR info:    no
  Residence:           SLP_Full_Backups
  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:  no
  Enable Metadata Indexing:  no
  Index server name:  NULL
  Use Accelerator:  no
  HW/OS/Client:  HYPER-V       Virtual_Machi server1.some.be
                 HYPER-V       Virtual_Machi server2.some.be
                 HYPER-V       Virtual_Machi server3.some.be
                 HYPER-V       Virtual_Machi server4.some.be
                 HYPER-V       Virtual_Machi server5.some.be
                 HYPER-V       Virtual_Machi server6.some.be
some
  Include:  ALL_LOCAL_DRIVES

  Schedule:              Full_Backups
    Type:                Full Backup
    Frequency:           every 7 days
     Excluded Dates----------
        No specific exclude dates entered
        No exclude days of week entered
    PFI Recovery:        0
    Maximum MPX:         1
    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:
          zondag     20:00:00  -->  maandag    02:00:00
          maandag    20:00:00  -->  dinsdag    02:00:00
          dinsdag    20:00:00  -->  woensdag   02:00:00
          woensdag   20:00:00  -->  donderdag  02:00:00
          donderdag  20:00:00  -->  vrijdag    02:00:00
          vrijdag    20:00:00  -->  zaterdag   02:00:00
          zaterdag   20:00:00  -->  zondag     02:00:00

  Schedule:              Incr_Backup
    Type:                Cumulative Incremental Backup
    Frequency:           every 1 day
     Excluded Dates----------
        No specific exclude dates entered
        No exclude days of week entered
    PFI Recovery:        0
    Maximum MPX:         1
    Retention Level:     0 (1 week)
    Number Copies:       1
    Fail on Error:       0
    Residence:           SLP_Incr_Backups
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
    Residence is Storage Lifecycle Policy:         1
    Schedule indexing:   0
    Daily Windows:
          zondag     20:00:00  -->  maandag    02:00:00
          maandag    20:00:00  -->  dinsdag    02:00:00
          dinsdag    20:00:00  -->  woensdag   02:00:00
          woensdag   20:00:00  -->  donderdag  02:00:00
          donderdag  20:00:00  -->  vrijdag    02:00:00
          vrijdag    20:00:00  -->  zaterdag   02:00:00
          zaterdag   20:00:00  -->  zondag     02:00:00

 

Nicolai
Moderator
Moderator
Partner    VIP   

Indeed frequency.

Just to keep out the obvious, for how long time do you retain the backup ?.

If you retain shorter than 1 week, what you see will be expected behavior of Netbackup.

I will call on a friend or two take a look at this thread as well.

Best Regards

Nicolai

Nicolai
Moderator
Moderator
Partner    VIP   

As a workaround: Remove client that causes 196 on Sunday, then add them one by one on Wednesday,Thursday Friday.

This should force the full to run on a new day.

ErwinVreys
Level 4

I'm using storage lifecycle policies in our backups. The final copy is kept for 6 weeks but the copies in between have a lifetime of 1 week, 2 weeks and expire after copy.

So the first copy is saved for 1 week on a dedup pool onsite, the second copy is saved for 2 weeks on another dedup pool at a secondairy location, the third copy is a staging copy which will expire a soon as the final copy is put on tape. The copy on tape will expire after 6 weeks.

regards,
Erwin

 

ErwinVreys
Level 4

I had this workaround in my head but I was hoping that this would not be necessary. I'm losing the flexibility of frequency based backups.

Is my storage lifecycle policy the cause of this behavior?

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

I agree with Nicolai - Weekly backup should run every 7 days but retention is only one week?
Why such short retention for Weekly? 
Although it might not be retention causing the scheduling issue.
(But the command output might be incorrect as retention is determined by SLP)

I normally troubleshoot frequency backup issues by looking at previous successful backups.

Show us output of:
bpimagelist -client <client-name> -pt Hyper-V -d 01/26/2015 -U

Have you tried to predict next scheduled backup with nbpemreq?

Have you checked in Activity Monitor if backup that was attempted on Monday was scheduled or immediate (manually kicked off)?

Nicolai
Moderator
Moderator
Partner    VIP   

Good post from Marianne.

We really need to know the retention of the SLP - Please post

ErwinVreys
Level 4

All,

My apologies for not answering anymore. I became ill that day and had to stay home for a couple of days to recover. Last week I had a couple days of vacation planned and we had to move our servers to a brand new datacenter.

I asked a colleague to follow the problem but got scared from NetBackup. He made a change in the name of the schedule which had quit an impact. He saw a typo error in the name of the backup schedule. The title was not consistent with all the other schedules. So he changed the name of the schedule not knowing what the impact was. Either I was not aware of the impact. Unfortunately he changed the full backup schedule so during the night NetBackup started full backups of every machine in the policy.

To get everything back to normal I started scripting bpbackup commands everyday which started full backup of particular machines at the end of the day. While doing this I actually also noticed that I was mistaken when saying that executing a full backup did not shift the schedule. I'm not familiar with NetBackup commands but I started using bpimagelist to investigate my problem. The backups were shifting but I have a few servers with almost the same name. I overlooked the name difference. I think my illness clouded my judgment together with planning the move to our new datacenter. This was not an ideal cocktail to investigate a problem.

The final conclusion is that my backup window was indeed too small that particular day. Now every backup is running normal within the planned backup window due to work I had to do after the name change.

Regards,
Erwin

Nicolai
Moderator
Moderator
Partner    VIP   

Thanks you for the update

I have marked yore last post as a solution due to the fine wrap-up.