cancel
Showing results for 
Search instead for 
Did you mean: 

BUG REPORT: NDMP incremental backup running as a full backup

SilvioLuciano
Level 3

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.

2 ACCEPTED SOLUTIONS

Accepted Solutions

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

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!

View solution in original post

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

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. 

View solution in original post

11 REPLIES 11

Mike_Gavrilov
Moderator
Moderator
Partner    VIP    Accredited Certified

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.

Hi, I'm in version 7.6.1.

Mike_Gavrilov
Moderator
Moderator
Partner    VIP    Accredited Certified

>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.

Which records you need, Mike?

Mike_Gavrilov
Moderator
Moderator
Partner    VIP    Accredited Certified

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?

Of course! Follow the log.

Thanks for the help.

Mike_Gavrilov
Moderator
Moderator
Partner    VIP    Accredited Certified

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?

 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

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!

Lowell_Palecek
Level 6
Employee

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.

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.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

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.