Accelerator forced rescan

[BirtyB]

Suppose we have a NBU accelerator enabled vmware policy which targets a vm folder within vSphere containing 100 vm's.  One of these vm's does not backup successfully and results with the dreaded "media write error (84)" error. More specifically:

14/08/2016 19:42:14 - Critical bptm(pid=7012) A portion of data to be included from a previous backup (backupid = DFS1_1470674790, offset = 421490682880, length = 131072) has incorrect checksum (calculated checksum from backup image 7426e48b4836b926b6a2bcce56ad6cab48d78e5c, expected checksum dc41a018177c1dcdbb710bd8697d8171f7b13730)
14/08/2016 19:42:14 - Critical bptm(pid=7012) image write failed: error -1: plugin error
14/08/2016 19:42:18 - Error bptm(pid=7012) cannot write image to disk, Invalid argument
14/08/2016 19:42:18 - Info bptm(pid=7012) EXITING with status 84 <----------
14/08/2016 19:42:18 - Error bpbrm(pid=7496) from client DFS1: ERR - tar file write error (14)

Under these circumstances Veritas support advise enabling the "Accelerator forced rescan" option within the policy schedule however, this is not ideal because we do not need to rescan the other 99 machines within the policy, only the vm that has failed to backup.

What is the best way to force a rescan of only the affected vm and not the rest of the machines covered within the same policy?   

[Systems_Team]

Hi BirtyB,

The easiest way for this is to create a separate VM policy you can use for these type of scenarios.

I use VMware Intelligent Policies, and clients are selected on the fly based on a couple of criteria.  The downside with these policies is that I cannot run a manual backup on just one of them, as all VM's will be backed up.

For these cases I have a separate policy VM_Test.  This I can configure however I like, and I add a single client - either via a VIP query based on the VM's VMDNSname attribute, or selecting manually.  You can have a full schedule in the policy with an accelerator forced rescan.  Hopefully this will clear up your issue - maybe the change track log is screwed up.

I quite often use this method when I want to work with just one problem VM.  I know it is not backing up under the same policy, but it does allow me to work with just the one VM.

Hope this helps,

Steve