Incremental VMware Backups of Windows VMs may fail with Status 84 intermittently to deduplication storage if filesystem is not property quiesced

Article: 100010632
Last Published: 2019-10-26
Ratings: 1 3
Product(s): NetBackup & Alta Data Protection

Problem

When performing incremental mapped fullVM backups of Windows VMs to deduplication storage, the backups may fail with Status 84 (media write error) due to inconsistent data in the VMware snapshot.

Error Message

Detail Status:
22/08/2013 14:26:39 - Critical bptm(pid=6698) image write failed: error 2060022: software error      
22/08/2013 14:26:45 - Error bptm(pid=6698) cannot write image to disk, Invalid argument      
22/08/2013 14:26:46 - Error bpbrm(pid=6684) from client VMCLIENT02: ERR - bpbkar exiting because backup is aborting  
22/08/2013 14:26:46 - Info bptm(pid=6698) EXITING with status 84 <----------
 
PDPlugin failure:
08/22/13 14:26:39 [6698:bptm] [6698] [DEBUG] PDSTS: fbu_fill_bitmap: (2417) stream_offset=727214080, file_offset=8192, length=16384, fsize=155100
08/22/13 14:26:39 [6698:bptm] [6698] [ERROR] PDSTS: fbu_fill_bitmap: (2416) stream_offset(727214080) + length(16384) > (2417) stream_offset(727214080)
08/22/13 14:26:39 [6698:bptm] [6698] [ERROR] PDSTS: fbu_scan_buf: fbu_fill_bitmap() failed (2060022:software error)
08/22/13 14:26:39 [6698:bptm] [6698] [ERROR] PDSTS: write_special_buf: fbu_scan_buf failed: (2060022:software error)
 
bpbkar:
14:26:35.156 [6697] <4> catalogName_PS: INF - File System Name to catalog VMFILE0
14:26:35.157 [6697] <2> put_maphdr: Called with name = /\\.\VMFILE0, type = 2 (../flashmap.cpp:886)
14:26:46.031 [6697] <16> bpbkar copy_to_shm: ERR - bpbkar exiting because backup is aborting
14:26:46.031 [6697] <16> bpbkar Exit: ERR - bpbkar FATAL exit status = 40: network connection broken
14:26:46.031 [6697] <2> vxms_shutdown: vxms_started = 1 (../vxms_bridge.cpp:863)

Cause

The issue occurs due to a dirty snapshot of the virtual machine, that did not properly quiesce the filesystem of the virtual machine.  The data in the memory/cache has not been flushed to the filesystem, causing unexpected scenarios like identical i_block information from multiple inodes.

Solution

See multiple solutions below:
  1. Verify that VMware VSS Provider is installed in the virtual machine.
  1. If VMware VSS Provider is installed, it maybe not properly quiescing the filesystem.  Try another VSS Provider such as Veritas VSS Provider:
See 'Solution' section in the following: 
  1. Shutdown the virtual machine and perform the incremental backup.  If this works, they it proves that the snapshot is not properly quiescing the filesystem.
 

Applies To

This issue can occur when the VMware VSS Provider is not installed on the Windows VM, thus disabling the ability to quiesce the filesystem.

Was this content helpful?