First, verify that you have this problem. Access the repository file system and locate the folder containing the VM backup in question. Locate the last successful backup for this VM. If you have not yet recreated the job, it will be the most recent savepoint in the last savepoint set folder.
Each backup savepoint will write two metadata files, One of these file names will end in Manifest.metadata and the other will end in VmConfig.metadata. The savepoint will also write a .var file for each disk being backed up.
Count the number of .var files produced by the backup; it should match the number of disks backed up on the VM. Then, open the most recent Manifest.metadata file. You can open this with your favorite text editor. Look for lines that start with <FileMapEntry as the first few characters. You should have one of these entries for each .var file. If you have the problem that has been observed, you will have fewer of the <FileMapEntry lines than you have .var files.
If this is the case, then this savepoint is causing your subsequent backups to fail. To work around the problem, in vRanger go to the My Repositories view, locate the bad savepoint, highlight by clicking it, and select Remove. This will remove the savepoint from the database, but it will not remove all of the savepoint from the repository. That is because vRanger reads the savepoint manifest file to determine what files to remove, and one of the .var files is not in the manifest file. Open the repository file system and delete the directory containing the savepoint. This will complete the cleanup of the bad savepoint. Subsequent backups will now work.
