If tolerable, the easiest way out is to start fresh. Once files get mixed together from two machines, pulling the files apart again may be difficult or impossible (depending on what other actions have happened in the meanwhile). Theoretically you can look at the names of the missing files to try to determine the severity of the lost files. A dlist or dindex can sometimes be regenerated from the database. A lost dblock cannot, but what’s not known is whether it belongs to the backup you care about, or the one you don’t (i.e. the old VM).
Databases contain clues, however unless you copied the one you deleted, I’m not sure that it’s backed up. You could look around for a file of about the right size and date sitting in the folder with Duplicati databases. Alternatively you could assume that things mentioned in the old VM database can probably be sacrificed as irrelevant to the new VM backup. You can get a list of the backup times from the old VM UI, and try to see if those match up with file dates on B2. Date methods might fail if backups ran scheduled and simultaneous. Attempting to assess damage (or not) to specific versions can also be tried, e.g. by testing direct restores.
Starting fresh could be an export and import into a new backup (then adjust the names, folders, and such), or you could just delete the local database and the remote files. Configuration is stored separately, so next backup run will be like the initial backup run. I don’t know how much data there is. Restarts can take awhile. One advantage to keeping a damaged backup around when restarting is it might still have some use if one wants to try extreme measures at some future point to restore a version that the new backup doesn’t have.