Forum Discussion

mrauf's avatar
mrauf
Level 4
10 years ago

media write error (84) in VMWare Backup.

Hi 

have observed that my VMware Backups are getting failed with error media write error (84), we are using netbackup 7.6.1.1 on windows 2008 R2 Enterprise 64 bit Platform.

 

please find the job details below

6/6/2015 9:07:39 AM - Info nbjm(pid=22060) starting backup job (jobid=611356) for client PBAD-DC2, policy VMWare_Daily_SAN_Backup, schedule Daily  
6/6/2015 9:07:40 AM - estimated 31632424 Kbytes needed
6/6/2015 9:07:40 AM - Info nbjm(pid=22060) started backup (backupid=PBAD-DC2_1433570859) job for client PBAD-DC2, policy VMWare_Daily_SAN_Backup, schedule Daily on storage unit Netbackup_StorageUnit using backup host pbad-netbackup.pbad.sbg.com.sa
6/6/2015 9:07:40 AM - started process bpbrm (4832)
6/6/2015 9:07:41 AM - Info bpbrm(pid=4832) PBAD-DC2 is the host to backup data from     
6/6/2015 9:07:41 AM - Info bpbrm(pid=4832) reading file list for client        
6/6/2015 9:07:42 AM - Info bpbrm(pid=4832) accelerator enabled           
6/6/2015 9:07:45 AM - Info bpbrm(pid=4832) starting bpbkar32 on client         
6/6/2015 9:07:45 AM - connecting
6/6/2015 9:07:45 AM - connected; connect time: 0:00:00
6/6/2015 9:07:46 AM - Info bpbkar32(pid=21892) Backup started           
6/6/2015 9:07:47 AM - Info bpbkar32(pid=21892) accelerator enabled backup, archive bit processing:<disabled>       
6/6/2015 9:07:47 AM - Info bptm(pid=1148) start            
6/6/2015 9:07:47 AM - Info bptm(pid=1148) using 524288 data buffer size        
6/6/2015 9:07:47 AM - Info bptm(pid=1148) setting receive network buffer to 2098176 bytes      
6/6/2015 9:07:47 AM - Info bptm(pid=1148) using 128 data buffers         
6/6/2015 9:07:48 AM - Info bptm(pid=1148) start backup           
6/6/2015 9:07:50 AM - begin writing
6/6/2015 9:09:18 AM - Info bpbkar32(pid=21892) INF - Transport Type =  nbd      
6/6/2015 9:09:34 AM - Critical bptm(pid=1148) A portion of data to be included from a previous backup (backupid = PBAD-DC2_1432943456, offset = 350832640, length = 131072) has incorrect checksum (calculated checksum from backup image 5a7a8e94f27c3c162e8c867b44df2cda1c09868b, expected checksum aa80546d788b65a523243bd49e5544e1d4163e9e)
6/6/2015 9:09:34 AM - Critical bptm(pid=1148) image write failed: error -1: plugin error      
6/6/2015 9:09:47 AM - Error bptm(pid=1148) cannot write image to disk, Invalid argument      
6/6/2015 9:09:47 AM - Info bptm(pid=1148) EXITING with status 84 <----------        
6/6/2015 9:09:47 AM - Error bpbrm(pid=4832) from client PBAD-DC2: ERR - tar file write error (14)   
6/6/2015 9:09:48 AM - Info bpbkar32(pid=21892) accelerator sent 0 bytes out of 0 bytes to server, optimization 0.0% 
6/6/2015 9:09:49 AM - Info bpbkar32(pid=21892) bpbkar waited 11 times for empty buffer, delayed 651 times.   
6/6/2015 9:09:50 AM - Info pbad-netbackup.pbad.sbg.com.sa(pid=1148) StorageServer=PureDisk:pbad-netbackup.pbad.sbg.com.sa; Report=PDDO Stats for (pbad-netbackup.pbad.sbg.com.sa): scanned: 342792 KB, CR sent: 13062 KB, CR sent over FC: 0 KB, dedup: 96.2%, cache disabled
6/6/2015 9:09:50 AM - Error bpbrm(pid=4832) could not send server status message       
6/6/2015 9:09:51 AM - Critical bpbrm(pid=4832) unexpected termination of client PBAD-DC2        
6/6/2015 9:10:01 AM - Info bpbkar32(pid=0) done. status: 84: media write error       
6/6/2015 9:10:01 AM - end writing; write time: 0:02:11
media write error (84)

  • Metadata corruption!

    You'll have to enable Accelerator forced rescan and perform a new full backup.  I think that'll sort you out and if it does, you can then disable Accelerator forced rescan again.

    (jandersen was onto this first)

    There's a good recommendation in this TechNote:

    The Symantec recommendation is to define at least two full schedules in the Accelerator policy.  The first full schedule to define when the full backups run more frequently without the ' Accelerator forced rescan ' option enabled, and another full schedule to run less often (perhaps, once a month, every six months or once a year), with the ' Accelerator forced rescan ' option enabled.  Having the forced rescan option enabled, ensures the Accelerator track log is refreshed to avoid any problems with future Accelerator backups.

    Accelerator Forced Rescan option being set or used when it is not defined in the Accelerator policy full schedule
     http://symantec.com/docs/TECH222420

    If you already have two full schedules set up, one with and one without, give the one WITH a manual run.

    This is also said in the manual page:

    Accelerator forced rescan option (schedule attribute)
     http://symantec.com/docs/HOWTO106425

  • Metadata corruption!

    You'll have to enable Accelerator forced rescan and perform a new full backup.  I think that'll sort you out and if it does, you can then disable Accelerator forced rescan again.

    (jandersen was onto this first)

    There's a good recommendation in this TechNote:

    The Symantec recommendation is to define at least two full schedules in the Accelerator policy.  The first full schedule to define when the full backups run more frequently without the ' Accelerator forced rescan ' option enabled, and another full schedule to run less often (perhaps, once a month, every six months or once a year), with the ' Accelerator forced rescan ' option enabled.  Having the forced rescan option enabled, ensures the Accelerator track log is refreshed to avoid any problems with future Accelerator backups.

    Accelerator Forced Rescan option being set or used when it is not defined in the Accelerator policy full schedule
     http://symantec.com/docs/TECH222420

    If you already have two full schedules set up, one with and one without, give the one WITH a manual run.

    This is also said in the manual page:

    Accelerator forced rescan option (schedule attribute)
     http://symantec.com/docs/HOWTO106425

  • Hi
     

    I'm not sure at all, but this could maybe be related to https://support.symantec.com/en_US/article.TECH222588.html though this specifically mentions hot-add as transport and you are using NBD.

    I have also seen these status 84 errors on the accelerated VMware backups using NBD (as yours). A rerun of the same client most often cures the problem. If this doesn't work try with accelerator forced rescan (schedule property)

    I have actually not seen these errors before 7.6.1.1 and I'm curious whether this is solved in 7.6.1.2 which you could give a try.

    Have you tried to raise a case with support regarding this issue?

     

  • Best to log a Support call with Symantec. Not sure if anyone on this forum can help with the checksum error: 6/6/2015 9:09:34 AM - Critical bptm(pid=1148) A portion of data to be included from a previous backup (backupid = PBAD-DC2_1432943456, offset = 350832640, length = 131072) has incorrect checksum (calculated checksum from backup image 5a7a8e94f27c3c162e8c867b44df2cda1c09868b, expected checksum aa80546d788b65a523243bd49e5544e1d4163e9e)