Bugfix/feature req - jobs have drive letter of removed rep

[Unreliably-Recurring]

Case # 03104208: Backup tapes show drive letter of removed repository
I didn't post this in Tape because the info the Support engineer got internally indicated that the "cause" (as I perceive it) is an artifact of B & R's database's current referential integrity method.

When beginning the migration to Veeam B & R, I had a repository at an iSCSI LUN, connected in Windows as drive letter "V:\".
Once the old software was done using the local storage ("N:\"), I followed the steps at kb1729 to update the source backup jobs' repositories, removed the old repository, and then removed the drive from Windows.

Backup to Tape jobs run since then continue having an empty reference to the "V:\"-pathed repository.

My questions to, and responses from, the engineer:

1. What is the relationship between the source VM and the repository on which its backup is/was stored?".
   "During a VM backup to disk, its location (regarding host and datastore) and its reference IDs are stored both in the repository inside the restore point, and it is also stored within our database.
   During backup to tape jobs, the tape job will look into the database for records of a latest backup for the VM so that it can be written to tape.
   The backup to tape job then writes the catalog to C:\VBRCatalog by default.
   The tape catalog has a single reference to a media id within our database which links through a few different tables where we eventually get to a backup id which will hold the information of the repository."
2. How would Veeam B. & R. use the info about a path to a Repository that it knows doesn’t exist?
   Regarding the second question, I after discussion with various colleagues it seems the biggest concern that was voiced the most was that if you were to restore the backups as a file from tape restore and then specified the original location as the destination that it might fail.
   However, I did test this myself on one of the tapes that did have a reference to the old repository and it was able to restore to the original location without any problems, so even with the reference still visible it does not seem to pose a threat for future restores.

Since the answer to both questions seem to be, succinctly, that B & R doesn't care about a deleted repository path, why does it continue to show that path on the tape?

[Dima P.]

Hello Unreliably-Recurring.

Every backup file is treated as a regular file when Veeam B&R writes it to tape. Every file must have it's own original location (we provide the way to restore any file to original location, as otherwise restore might be more complex then it should). May I ask why you want this path to be removed in your case (as it looks like it does not affect any part of your restore procedure)? Thank you in advance.

[Unreliably-Recurring]

Every file must have it's own original location (we provide the way to restore any file to original location,...).

The files on the tape didn't come from "V:", B & R knows that, and shows that on the tape by not listing anything within "V:\".
The tape shows that it doesn't have any files that would be restored to that "original location".
Here's a screen snip of what B & R shows for an example tape's content.

If it doesn't affect restoring, then what's the problem?

(^ Paraphrased)
If the data didn't come from "V:\", and a ghost of "V:\" on the tape doesn't affect the restore, then why does a ghost of "V:\" on the tape/in the job exist?

1. The "original location" doesn't exist.
2. B & R's knows that the "original location" doesn't exist: it's not listed among Backup Repositories.
3. B & R can't automagically cause that "original location" to exist again to re-create the Backup Repository that was there.
4. B & R wouldn't prompt me to specify an alternate path for "V:\" if I restore something from the tape: it knows that the job didn't put anything from there onto the tape.
   It shows that by not listing anything within "V:\" on the tape.

[Dima P.]

B & R's knows that the "original location" doesn't exist: it's not listed among Backup Repositories.

Information about original location is stored not only in Veeam B&R catalog but on tape media as a metadata. Since tape stream cannot be easily modified (without erasing the tape content) the information about actual original location will be displayed anyway.

[Unreliably-Recurring]

Thank you for checking back.
After a short erase, Veeam shows no "original location" data on the tape.
The Case referenced in my originating post has discussion of, and logs attached that show, the tapes being short-erased when they're returned from off-site and imported into the library