Veeam B&R: Virtual disk size is not a multiple of 1KB

We are using Veeam B&R ver 9.x application to backup some esxi guests. From past few days we were getting error at one guest (Windows 2008 R2, converted from P2V (using vmware converter) & it’s backup worked well with veeam for long without issue, but after increasing its disk space, it was giving trouble with following errors.

I tried the veeam knowledge base mentioned here, changed disk size and recalculated, but still getting errors.

This VM have 2 drives assigned, 1st contains OS (C: drive), 2nd drive (G: Drive) contains Oracle DB DATA. To further narrow down the troubleshooting, I included only drive 1 (OS) in the Veeam backup job, and it worked fine. So it was confirmed that the culprit was drive 2 & it was important drive because it contains oracle database folders (ORACLE & USR).

Workaround:

I tried all solutions but couldn’t figured out. As a last resort I did following. I know this workaround is not the proper solution, but since I failed to sort it using my limited knowledge & get the VM backup was crucial, therefore I did following & it worked for me. Luckily I had enough resources to cater the workaround. 6 drivers SSD in Raid-5 made the transition really fast at about 6-7 Gbps.

STEPS:

• I Stopped all running services on the VM guest related to Oracle/SAP or any un-necessary apps
• Added new disk (drive3 / H: ) on the effected VM with same size as existing DB drive (disk2 G: )
• Cloned the partition from old (disk2 G: ) to this new (disk3 H: ) [I used 3rd party DiskGeniusPro tool for cloning by locking partition access, but u can use Robocopy or other tools as well)
• Using Disk Management, I changed the drive letter & marked the old (disk2 G: ) OFFLINE.
• Changed the new disk (disk3 H: ) partition drive letter same as older one that is  G:
• Rebooted the server, & this time all backups went smoothly & SAP ORACLE synching/services are working fine as well
• Afterwards I removed the OLD faulty partition from the VM.

Alhamdolillah!

Another workaround I got from a virtualization expert member at spicework community support named  Supaplex was to

“A slightly simpler option would be using a P2V approach inside the virtual machine using a free tool like V2V Converter https://www.starwindsoftware.com/starwind-v2v-converter and specifying your faulty G: disk as source and ESXi as the target. The tool would convert the disk into a fresh new VMDK file automatically, and all you would have to do is just attach it to the virtual machine and remove the old one. Hope that may save you some time in the future if you encounter such a problem again.”