06-27-2012 07:12 AM
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!
Solved! Go to Solution.
07-05-2012 05:10 AM
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!
06-27-2012 08:20 AM
Why the mix of Calendar and Frequency schedules ?
06-27-2012 10:04 AM
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
06-27-2012 12:33 PM
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?
07-02-2012 07:24 AM
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
07-02-2012 07:59 AM
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?
07-02-2012 08:28 AM
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!
07-02-2012 11:32 AM
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
07-02-2012 12:26 PM
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.
07-03-2012 05:56 AM
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
07-03-2012 07:26 AM
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.
07-05-2012 05:10 AM
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!