Job failed, but backups succeeded

The error message is pretty clear - obviously there is a 4th VM involved which has not been inventoried yet. So this cannot be backed up. But the backup of the 3 known ones did run successfully.

Unfortunately we do not see your configuration so it is hard to guess what is really wrong. But if you open the log file, it will most likely tell you more. Do not forget that you should not read it with a standard text editor but nsr_render_log to get the variables exchanged with their true names.

you get these errors, simply when deleting a VM from VC inventory, without first having removed the VM from the protection group. Then the UUID reference will be left. The (just only slightly) improvement with nw19.5 onwards, is at at least that now in the backup log it will mention the name of the of the VM, not just the UUID, based on the previous backup where it still new what the VM name was.

So when then editing the protection group, it will "solve" the old reference.

We are going for using VC end tags, so to have dynamic selection occurring. That way this kind of simple error, would not occur as only when the backup is actually run, it will start looking for any VM with the required tag(s) to be used for selection. Any VM no longer existing, would have no tag reference and hence cannot end up in the dynamic selection.

The major drawback of the dynamic tag-based selection approach is, that nowhere within NW you will see any VM being referenced to a protection group anymore. So you wouldn't know what the backup configuration is for such a VM.

This has been raised with the global product manager for the DPS suite at Dell (one of many "issues" we have with NW).

Currently NW does not offer any (easy) way to show what the backup configuration is for any system (as - in my opinion - it should contain the information of all clients and the workflow they are connected to via their protection group to even determine if a backup is actively scheduled, which you cannot see only from client definition). This requires own scripting parsing said information and matching it to each other, simply to be able to try to found out what schedule even applies, as it can be set on client level, but it depends on the client can/cannot override setting and if it is even set on client level. There should be one single overview showing all these settings, not needing to go into separate views for clients/workflows/backup actions.

However as said for these dynamic selections, nothing can be shown even. You only have the backups being made or clicking each and every separate protection group and run a preview to see which vm's are using the tag set for that protection group.

So from auditing perspective this is a big miss, as one should be able to state what the backup configuration is for any asset. Now we can't.

have the same problem with same version

I remove one VM, validate group, and then I add the removed VM to his original group

Next day, problem disappeared