10-25-2016 06:19 AM - edited 10-25-2016 09:12 AM
We have the same error reported in the article https://www.veritas.com/support/en_US/article.000011201, is there any solution already known to fix the problem?
Information about my backup:
- NetBackup version 7.6.1
- Full backup performed on Saturday finished in status 0
- Incremental backup made on Monday finished in status 0 (previous backup to the problem).
- Incremental backup performed on Tuesday is the problem. This backup copying this all again the same data expected to complete.
Solved! Go to Solution.
10-26-2016 02:27 AM
We need to know which backup job (bpbrm PID) we're looking at in bpbrm.
There seem to be different NDMP backups that ran on this day. Some level 0, some level 2 and also level 7.
e.g.
08:53:29.039 [6860.9932] <2> logparams: -backup -S cansbkp03 -c cansfile01.sa.agcocorp.com -ct 19 -ru root -cl CAN_NAS_MAN -sched Semanal_NAS -bt 1477392807 -dt 0 -st 0 -b cansfile01.sa.agcocorp.com_1477392807 -mediasvr cansbkp05 -jobid 930985 -jobgrpid 930984 -masterversion 760000 -maxfrag 1048576 -bpstart_time 1477393108 -reqid -1477392692 -mt 3 -to 0 -stunit cansbkp05-hcart2-robot-tld-5-cansfile01.sa.agcocorp.com -rl 3 -rp 2678400 -eari 0 -cj 1 -D 14 -rt 8 -rn 5 -pool Semanal_NAS -use_ofb -use_otm -jm -secure 1 -kl 1 -rg other -fso -stream_count 1 -stream_number 1 -dmplevel 0 -connect_options 16974338
Herewith couple of TNs that may help:
NDMP backups - What triggers an Incremental versus a Full backup ?
http://www.veritas.com/docs/000009728
NDMP backup levels
http://www.veritas.com/docs/000076815
PS:
Please upload files in .txt format rather than .log (e.g. bpbrm.txt).
.txt files can be viewed online, even on a mobile device.
Not the case with .log....
THANKS!
10-27-2016 01:35 AM
Have you had a chance yet to look at the TNs that I've posted yesterday?
You will see that /etc/dumpdates on the filer determines which dumplevel to use.
If the Full was still running, it means that /etc/dumpdates on the filer was not yet updated with details of successful Full backup.
10-25-2016 08:41 AM
What version you're at? It was very old bug. It wasn't mentioned in any EEB guides (7.5, 7.6, 7.6) but I'm pretty sure that it's alrady fixed.
10-25-2016 08:51 AM
Hi, I'm in version 7.6.1.
10-25-2016 09:17 AM
>Please contact NetBackup Technical Support and request a binary fix (ET2219379).
"Request a binary fix" means that the EEB was already release but Tech Support was giving it only for the customers. Could you show your logs, please.
10-25-2016 09:29 AM
Which records you need, Mike?
10-25-2016 09:47 AM
Silvio,
I think it's better to start with bpbrm log because main problem is that ndmp agent rejects dmplevel 2. Could you share it, please?
10-25-2016 10:09 AM
Of course! Follow the log.
Thanks for the help.
10-25-2016 03:40 PM
I see several attempts in logs but there is a pattern. Backup starts and then it faces unexpected error.
02:47:26.076 [10792.9684] <2> bpbrm write_continue_backup: wrote CONTINUE BACKUP on COMM_SOCK <752> 02:47:26.076 [10792.9684] <2> write_file_names: buffering file name 'SET DIRECT = yes' for output 02:47:26.076 [10792.9684] <2> write_file_names: buffering file name 'SET HIST = yes' for output 02:47:26.076 [10792.9684] <2> write_file_names: buffering file name 'SET OPTION = NT' for output 02:47:26.076 [10792.9684] <2> write_file_names: buffering file name 'SET TYPE = TAR' for output 02:47:26.076 [10792.9684] <2> write_file_names: buffering file name 'SET SNAPSURE = no' for output 02:47:26.076 [10792.9684] <2> write_file_names: buffering file name '/fs_cansfile01/AGCO_CANOAS/Projeto' for output 02:47:26.076 [10792.9684] <2> write_file_names: successfully wrote buffer to COMM_SOCK 02:47:26.076 [10792.9684] <2> bpbrm main: wrote CONTINUE on COMM_SOCK 02:47:26.076 [10792.9684] <2> bpbrm main: closing COMM_SOCK 02:47:26.076 [10792.9684] <2> bpbrm main: Value of PFI = 0 02:47:26.076 [10792.9684] <2> bpbrm main: ESTIMATE -1 -1 cansfile01.sa.agcocorp.com_1477370843 03:19:21.578 [10792.9684] <2> bpbrm check_for_terminate: unexpected terminate 03:19:21.578 [10792.9684] <2> signal_ndmpagent: sending signal=1 to ndmpagent on cansbkp05, client_pid=9256 03:19:21.578 [10792.9684] <2> bpcr_send_signal: Ignoring connect_opts = 0x01030202
The TechNote you mentioned doesn't match your case because bpbrm was able to pass dmplevel to the ndmp agent.
Could you share logs for the same date from folders C:\Program Files\Veritas\NetBackup\logs\ndmpagent\ and C:\Program Files\Veritas\NetBackup\logs\bptm?
10-26-2016 02:27 AM
We need to know which backup job (bpbrm PID) we're looking at in bpbrm.
There seem to be different NDMP backups that ran on this day. Some level 0, some level 2 and also level 7.
e.g.
08:53:29.039 [6860.9932] <2> logparams: -backup -S cansbkp03 -c cansfile01.sa.agcocorp.com -ct 19 -ru root -cl CAN_NAS_MAN -sched Semanal_NAS -bt 1477392807 -dt 0 -st 0 -b cansfile01.sa.agcocorp.com_1477392807 -mediasvr cansbkp05 -jobid 930985 -jobgrpid 930984 -masterversion 760000 -maxfrag 1048576 -bpstart_time 1477393108 -reqid -1477392692 -mt 3 -to 0 -stunit cansbkp05-hcart2-robot-tld-5-cansfile01.sa.agcocorp.com -rl 3 -rp 2678400 -eari 0 -cj 1 -D 14 -rt 8 -rn 5 -pool Semanal_NAS -use_ofb -use_otm -jm -secure 1 -kl 1 -rg other -fso -stream_count 1 -stream_number 1 -dmplevel 0 -connect_options 16974338
Herewith couple of TNs that may help:
NDMP backups - What triggers an Incremental versus a Full backup ?
http://www.veritas.com/docs/000009728
NDMP backup levels
http://www.veritas.com/docs/000076815
PS:
Please upload files in .txt format rather than .log (e.g. bpbrm.txt).
.txt files can be viewed online, even on a mobile device.
Not the case with .log....
THANKS!
10-26-2016 07:13 AM
I don't know the answer to the main question, but I can clarify two points:
The fix mentioned in the TechNote (EEB 2219379) was included in NetBackup 7.1, so you have it in 7.6.1.
The bpbrm "unexpected terminate" occurs when a job is canceled. Nbjm signals a semiphore, and bpbrm detects it. It is not something that bpbrm decides on its own or receives from a client. Bpbrm exits with status 150.
10-26-2016 07:49 AM
Dear, as I am forwarding the information requested, however after the last backup diff (this was what sued equal to the full) I started a new diff, and this finished as expected, just copying the latest changes.
I take the case to ask: When the DIFF backup started, one of the NDMP policy was still processing the FULL. I wonder if this contributed to the DIFF copy all locations.
Today I have the following policies:
- "CAN_NAS_AGCO_CANOAS_01"
- "CAN_NAS_AGCO_CANOAS_02"
- "CAN_NAS_AGCO_CANOAS_03"
- "CAN_NAS_AGCO_CANOAS_04"
- "CAN_NAS_MAN"
- "CAN_NAS_AGCO_CAN" <<<<< The FULL backup of this policy was still running when the DIFF previous policies began.
10-27-2016 01:35 AM
Have you had a chance yet to look at the TNs that I've posted yesterday?
You will see that /etc/dumpdates on the filer determines which dumplevel to use.
If the Full was still running, it means that /etc/dumpdates on the filer was not yet updated with details of successful Full backup.