cancel
Showing results for 
Search instead for 
Did you mean: 

Status 200 message "scheduler found no backups due to run

nbustarter380
Level 6

Hello,

 We are  updating are clients to a calendar base schedule, I updated a Solaris client policy the other day and the FULL backup failed with a status code 200 "scheduler found no backups due to run . I setup the same policy again yesterday and last night the backup received the same STATUS CODE 200.

 I have done numerous clients and they have run without issue.

 I read the the technote below this seems to not  apply to our situation

 A client backup receives a Status 200 message "scheduler found no backups due to run" when multiple backups of the same type are scheduled on the same day, for the same policy, with calendar-based scheduling.

 Solaris10 client

Here is the bbpplist -l output

Policy Name:       testwater01
Options:           0x0
template:          FALSE
audit_reason:         ?
Names:             (none)
Policy Type:       Standard (0)
Active:            yes
Effective date:    06/25/2012 23:59:59
Client Compress:   no
Follow NFS Mnts:   no
Cross Mnt Points:  no
Collect TIR info:      yes, with move detection
Block Incremental: no
Mult. Data Stream: yes
Perform Snapshot Backup:   no
Snapshot Method:           (none)
Snapshot Method Arguments: (none)
Perform Offhost Backup:    no
Backup Copy:               0
Use Data Mover:            no
Data Mover Type:           2
Use Alternate Client:      no
Alternate Client Name:     (none)
Use Virtual Machine:      0
Hyper-V Server Name:     (none)
Enable Instant Recovery:   no
Policy Priority:   0
Max Jobs/Policy:   6
Disaster Recovery: 0
Collect BMR Info:  yes
Keyword:           (none specified)
Data Classification:       -
Residence is Storage Lifecycle Policy:    no
Client Encrypt:    no
Checkpoint:        no
Volume Pool:       NetBackup
Server Group:      *ANY*
Granular Restore Info:  no
Exchange Source attributes:              no
Exchange 2010 Preferred Server: (none defined)
Application Discovery:      no
Discovery Lifetime:      0 seconds
Generation:      8
Ignore Client Direct:  no
Client/HW/OS/Pri:  testwater01-bkup Solaris Solaris10 0 0 0 0 ?
Include:           ALL_LOCAL_DRIVES
Schedule:          full
  Type:            FULL (0)
  Calendar sched: Enabled
    SPECIFIC DATE 0 - 06/26/2012
    SPECIFIC DATE 1 - 09/18/2012
    SPECIFIC DATE 2 - 12/11/2012
    SPECIFIC DATE 3 - 03/05/2013
    SPECIFIC DATE 4 - 05/28/2013
    SPECIFIC DATE 5 - 08/20/2013
    SPECIFIC DATE 6 - 11/12/2013
    SPECIFIC DATE 7 - 02/04/2014
    SPECIFIC DATE 8 - 04/29/2014
    SPECIFIC DATE 9 - 07/22/2014
  Maximum MPX:     1
  Synthetic:       0
  PFI Recovery:    0
  Retention Level: 11 (56 days)
  u-wind/o/d:      0 0
  Incr Type:       DELTA (0)
  Alt Read Host:   (none defined)
  Max Frag Size:   0 MB
  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
  Daily Windows:
   Day         Open       Close       W-Open     W-Close
   Sunday      000:00:00  007:00:00   000:00:00  007:00:00
   Monday      000:00:00  007:00:00   024:00:00  031:00:00
   Tuesday     000:00:00  007:00:00   048:00:00  055:00:00
   Wednesday   000:00:00  007:00:00   072:00:00  079:00:00
   Thursday    000:00:00  007:00:00   096:00:00  103:00:00
   Friday      000:00:00  007:00:00   120:00:00  127:00:00
   Saturday    000:00:00  007:00:00   144:00:00  151:00:00
Schedule:          synthetic
  Type:            FULL (0)
  Calendar sched: Enabled
    SPECIFIC DATE 0 - 07/24/2012
    SPECIFIC DATE 1 - 08/21/2012
    SPECIFIC DATE 2 - 10/16/2012
    SPECIFIC DATE 3 - 11/13/2012
    SPECIFIC DATE 4 - 01/08/2013
    SPECIFIC DATE 5 - 02/05/2013
    SPECIFIC DATE 6 - 04/02/2013
    SPECIFIC DATE 7 - 04/30/2013
    SPECIFIC DATE 8 - 06/25/2013
    SPECIFIC DATE 9 - 07/23/2013
    SPECIFIC DATE 10 - 09/17/2013
    SPECIFIC DATE 11 - 10/15/2013
    SPECIFIC DATE 12 - 12/10/2013
    SPECIFIC DATE 13 - 01/07/2014
    SPECIFIC DATE 14 - 03/04/2014
    SPECIFIC DATE 15 - 04/01/2014
    SPECIFIC DATE 16 - 05/27/2014
    SPECIFIC DATE 17 - 06/24/2014
    SPECIFIC DATE 18 - 08/19/2014
    SPECIFIC DATE 19 - 09/16/2014
  Maximum MPX:     1
  Synthetic:       1
  PFI Recovery:    0
  Retention Level: 11 (56 days)
  u-wind/o/d:      0 0
  Incr Type:       DELTA (0)
  Alt Read Host:   (none defined)
  Max Frag Size:   0 MB
  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
  Daily Windows:
   Day         Open       Close       W-Open     W-Close
   Sunday      008:00:00  016:00:00   008:00:00  016:00:00
   Monday      008:00:00  016:00:00   032:00:00  040:00:00
   Tuesday     008:00:00  016:00:00   056:00:00  064:00:00
   Wednesday   008:00:00  016:00:00   080:00:00  088:00:00
   Thursday    008:00:00  016:00:00   104:00:00  112:00:00
   Friday      008:00:00  016:00:00   128:00:00  136:00:00
   Saturday    008:00:00  016:00:00   152:00:00  160:00:00
Schedule:          incremental
  Type:            INCR (1)
  Frequency:       1 day(s) (86400 seconds)
    EXCLUDE DATE 0 - 06/26/2012
    EXCLUDE DATE 1 - 09/18/2012
    EXCLUDE DATE 2 - 12/11/2012
    EXCLUDE DATE 3 - 03/05/2013
    EXCLUDE DATE 4 - 05/28/2013
    EXCLUDE DATE 5 - 08/20/2013
    EXCLUDE DATE 6 - 11/12/2013
    EXCLUDE DATE 7 - 02/04/2014
    EXCLUDE DATE 8 - 04/29/2014
    EXCLUDE DATE 9 - 07/22/2014
  Maximum MPX:     1
  Synthetic:       0
  PFI Recovery:    0
  Retention Level: 11 (56 days)
  u-wind/o/d:      0 0
  Incr Type:       DELTA (0)
  Alt Read Host:   (none defined)
  Max Frag Size:   0 MB
  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
  Daily Windows:
   Day         Open       Close       W-Open     W-Close
   Sunday      000:00:00  007:00:00   000:00:00  007:00:00
   Monday      000:00:00  007:00:00   024:00:00  031:00:00
   Tuesday     000:00:00  007:00:00   048:00:00  055:00:00
   Wednesday   000:00:00  007:00:00   072:00:00  079:00:00
   Thursday    000:00:00  007:00:00   096:00:00  103:00:00
   Friday      000:00:00  007:00:00   120:00:00  127:00:00
   Saturday    000:00:00  007:00:00   144:00:00  151:00:00
 

 

Thanks for any help!

 

1 ACCEPTED SOLUTION

Accepted Solutions

nbustarter380
Level 6

Marianne,

Thanks for the Information and for all your respsones, we found the issue someone or somehow the etc/hosts file was changed on our Master Netbackup server. Netbackp uses the host name as the key to its database.

The full backup was run and completed successfully once that was fixed.

 

Again thanks for your help!

 

View solution in original post

11 REPLIES 11

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Why the mix of Calendar and Frequency schedules ?

nbustarter380
Level 6

Marianne, Thanks for your response

We are switiching from Frequency to calender based,  We use a script to created the new calendar based  schedule. In the script that was created it asks if we want to deactivate the  "OLD" policy (frequency schedule) we reply yes. then the script asks to create a new policy not sure if that answers your question?

All polices will be Calendar based now

 

Thanks

 

 

 


 

 

 

 

 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

I would trust what bppllist tells us rather than a script.... You should be able to confirm the following by looking at the policy in the GUI.

I see the following schedules in policy testwater01:

Schedule:          full
  Type:            FULL (0)
  Calendar sched: Enabled

Schedule:          synthetic
  Type:            FULL (0)
  Calendar sched: Enabled

Schedule:          incremental
  Type:            INCR (1)
  Frequency:       1 day(s) (86400 seconds)

 

Which of these schedules failed with 200?

 

 

nbustarter380
Level 6

Hi Marianne thanks!

Sorry for the late response, I was away for a couple of days the "Schedule full" is failing.  Since we are re-doing the policy schedule we start off with Full backups first.

 

Thanks again 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

You have 2 Full schedules of type Calendar:
full
synthetic

full starts with these SPECIFIC days:
    SPECIFIC DATE 0 - 06/26/2012
    SPECIFIC DATE 1 - 09/18/2012

synthetic:
    SPECIFIC DATE 0 - 07/24/2012
    SPECIFIC DATE 1 - 08/21/2012
    SPECIFIC DATE 2 - 10/16/2012

and then a Frequency based INCR schedule with frequency of every 1 day.
 

So, the one and only time so far that the initial full schedule was supposed to run was on 26 June @ 00:00 with  Effective date:    06/25/2012 23:59:59. (Cutting things very fine??)
Is this when the backup failed?
Have you tried to run a manual backup of this schedule in the meantime?

It is almost a week later.... What has been tried as a fix in the last week?

Without a full backup, what has happened to the daily Incrementals since the 26th?
 

nbustarter380
Level 6

Marianne,

Yes, the 6/26/2012  FULL is the one that failed our backups start a midnight, before that it was another date about a few days earlier that the FULL backup failed with the 200 status. So I deactivated the policy and created the 6/26/12 policy and the FULL backup failed again. Yes, I tried running the manual full backups both times (the morning that they failed)  and the manual full backups failed, again with the status 200. We have to get a full backup  the first time before any Incrementals are run but so far no luck on getting the full to complete successfully

Synthetics fulls are scheduled to run every four weeks (so not concerned about those)

UPDATE: I was told we are going to delete the backups for the policy and redo it because a  Incremental ran before a new policy was created. I'm not sure if that will fix the issue 

 

Thanks again for your responses!

 

Mark_Solutions
Level 6
Partner Accredited Certified

Only three things come to mind here:

1. You may need to change them to start at 00:05 to make sure the window does not close immediately - though that would not explain why a manual fails

2. Your script has corrupted the schedules - try making one manually to see if it then works

3. your schedules are out of sync - if you make a lot of chnages / have a lot of policies you should always run:

nbpemreq -updatepolicies

to make NetBackup re-read everything

Hope this helps

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

One more thought - have you checked/verified comms between master and client?

Seems client needs to be backed up via backup-lan: testwater01-bkup

Master needs to connect to client to resolve 'ALL_LOCAL_DRIVES' before job can be initiated.

Please create bpcd log on client.

Next, test connectivity as follows from Master:

bptestbpcd -client testwater01-bkup -debug -verbose

Please post command output as well as client's bpcd log.

nbustarter380
Level 6

Mark,  Marianne Thanks

Mark,

We use that script for  many many clients, I don't think that is the issue. Also, we did the following command

nbpemreq -updatepolicies

 

Marianne,

Yes,, the communication between server and client is good

Here is the bptestbpcd output

  

 [root@nbucorpe ~]# bptestbpcd -client testwater01-bkup -debug -verbose

07:50:09.203 [16876] <2> bptestbpcd: VERBOSE = 0

07:50:09.204 [16876] <2> ConnectionCache::connectAndCache: Acquiring new connect

ion for host nbucorpe, query type 223

07:50:09.204 [16876] <2> logconnections: BPDBM CONNECT FROM 127.0.0.1.43299 TO 1

27.0.0.1.13721 fd = 3

07:50:09.204 [16876] <2> vnet_get_user_credential_path: ../../libvlibs/vnet_vxss

.c.1464: 0: status: 35 0x00000023

07:50:09.205 [16876] <2> vnet_get_credential_path: ../../libvlibs/vnet_vxss.c.10

94: 0: vnet_get_user_credential_path failed: 35 0x00000023

07:50:09.205 [16876] <2> vnet_get_oc: ../../libvlibs/vnet_vxss_helper.c.3122: 0:

 Invalid Argument:: vxss_coninfo

07:50:09.209 [16876] <2> db_CLIENTsend: reset client protocol version from 0 to

7

07:50:09.249 [16876] <2> db_getCLIENT: db_CLIENTreceive: no entity was found 227

07:50:09.250 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6635:

0: fopen() failed: 2 0x00000002

07:50:09.250 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6636:

0: fopen() failed: /usr/openv/var/host_cache/155/8e39bb55+veritas_pbx,1,20,2,1,0

+testwater01-bkup.txt

07:50:09.251 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6635:

0: fopen() failed: 2 0x00000002

07:50:09.251 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6636:

0: fopen() failed: /usr/openv/var/host_cache/192/82f56992+0,1,402,0,1,0+126.2.2.

86.txt

07:50:09.251 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6635:

0: fopen() failed: 2 0x00000002

07:50:09.251 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6636:

0: fopen() failed: /usr/openv/var/host_cache/155/8e39bb55+vnetd,1,20,2,1,0+testu

idns02-bkup.txt

07:50:09.252 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6635:

0: fopen() failed: 2 0x00000002

07:50:09.252 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6636:

0: fopen() failed: /usr/openv/var/host_cache/155/8e39bb55+bpcd,1,20,2,1,0+testui

dns02-bkup.txt

07:50:09.256 [16876] <2> vnet_pbxConnect: pbxConnectEx Succeeded

07:50:09.256 [16876] <2> logconnections: BPCD CONNECT FROM 126.2.2.236.45107 TO

126.3.3.46.1556 fd = 3

07:50:09.256 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6635:

0: fopen() failed: 2 0x00000002

07:50:09.256 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6636:

0: fopen() failed: /usr/openv/var/host_cache/192/82f56992+veritas_pbx,1,20,2,1,0

+126.3.3.46.txt

07:50:09.257 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6635:

0: fopen() failed: 2 0x00000002

07:50:09.257 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6636:

0: fopen() failed: /usr/openv/var/host_cache/192/82f56992+vnetd,1,20,2,1,0+126.2

.2.86.txt

07:50:09.259 [16876] <2> vnet_pbxConnect: pbxConnectEx Succeeded

07:50:09.268 [16876] <2> do_pbx_service: ../../libvlibs/vnet_connect.c.1776: 0:

via PBX: VNETD CONNECT FROM 126.2.2.236.47495 TO 126.3.3.46.1556 fd = 4

07:50:09.268 [16876] <2> vnet_vnetd_connect_forward_socket_begin: ../../libvlibs

/vnet_vnetd.c.445: 0: VN_REQUEST_CONNECT_FORWARD_SOCKET: 10 0x0000000a

07:50:09.314 [16876] <2> vnet_vnetd_connect_forward_socket_begin: ../../libvlibs

/vnet_vnetd.c.462: 0: ipc_string: /tmp/vnet-16575341316208349897000004853-DBa4xG

07:50:09.357 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6635:

0: fopen() failed: 2 0x00000002

07:50:09.357 [16876] <2> file_to_addrinfo: ../../libvlibs/vnet_addrinfo.c.6636:

0: fopen() failed: /usr/openv/var/host_cache/1f6/1bc81df6+0,1,402,0,1,0+testuidn

s02.dcp.state.xx.us.txt

07:50:09.357 [16876] <2> vnet_get_user_credential_path: ../../libvlibs/vnet_vxss

.c.1464: 0: status: 35 0x00000023

07:50:09.357 [16876] <2> vnet_get_credential_path: ../../libvlibs/vnet_vxss.c.10

94: 0: vnet_get_user_credential_path failed: 35 0x00000023

1 1 1

126.2.2.236:45107 -> 126.3.3.46:1556

126.2.2.236:47495 -> 126.3.3.46:1556

07:50:09.396 [16876] <2> bpcr_get_peername_rqst: Server peername length = 24

07:50:09.397 [16876] <2> bpcr_get_hostname_rqst: Server hostname length = 11

07:50:09.398 [16876] <2> bpcr_get_clientname_rqst: Server client name length = 1

1

07:50:09.399 [16876] <2> bpcr_get_version_rqst: bpcd version: 07100000

07:50:09.399 [16876] <2> bpcr_get_platform_rqst: Server client platform length =

 9

07:50:09.399 [16876] <2> bpcr_get_version_rqst: bpcd version: 07100000

07:50:09.440 [16876] <2> bpcr_patch_version_rqst: theRest == > <

07:50:09.441 [16876] <2> bpcr_get_version_rqst: bpcd version: 07100000

07:50:09.481 [16876] <2> bpcr_patch_version_rqst: theRest == > <

07:50:09.481 [16876] <2> bpcr_get_version_rqst: bpcd version: 07100000

PEER_NAME = nbucorpe.dop.state.xx.us

HOST_NAME = testwater01

CLIENT_NAME = testwater01

VERSION = 0x07100000

PLATFORM = solaris10

PATCH_VERSION = 7.1.0.0

SERVER_PATCH_VERSION = -1.-1.-1.-1

MASTER_SERVER = nbucorpe.dop.state.xx.us

EMM_SERVER = nbucorpe.dop.state.xx.us

07:50:09.508 [16876] <2> vnet_pbxConnect: pbxConnectEx Succeeded

07:50:09.514 [16876] <2> do_pbx_service: ../../libvlibs/vnet_connect.c.1776: 0:

via PBX: VNETD CONNECT FROM 126.2.2.236.59641 TO 126.3.3.46.1556 fd = 5

07:50:09.514 [16876] <2> vnet_vnetd_connect_forward_socket_begin: ../../libvlibs

/vnet_vnetd.c.445: 0: VN_REQUEST_CONNECT_FORWARD_SOCKET: 10 0x0000000a

07:50:09.564 [16876] <2> vnet_vnetd_connect_forward_socket_begin: ../../libvlibs

/vnet_vnetd.c.462: 0: ipc_string: /tmp/vnet-16576341316208599849000004853-xFaayG

126.2.2.236:59641 -> 126.3.3.46:1556

<2>bptestbpcd: EXIT status = 0

07:50:09.607 [16876] <2> bptestbpcd: EXIT status = 0

 Also, Is there a link that discribes how to create the bpcd log on client.

Thanks again

 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Connectivity is fine, so we can discard that idea.

Legacy logs are enabled by simply creating a folder, e.g. mkdir /usr/openv/netbackup/logs/bpcd.
Described in Troubleshooting Guide.

nbustarter380
Level 6

Marianne,

Thanks for the Information and for all your respsones, we found the issue someone or somehow the etc/hosts file was changed on our Master Netbackup server. Netbackp uses the host name as the key to its database.

The full backup was run and completed successfully once that was fixed.

 

Again thanks for your help!