Disk to Tape Duplicate jobs randomly failing with error e0008105 - Invalid Physical Volume Library Media Identifier

[Artegic]

We're using BackupExec 2012 Rev. 1798 64 Bit with Service Pack 2 running on Microsoft Windows Server 2008 R2 Standard with a Tandberg T24 LTO-5 changer to back up a Windows 2008 file server and Active Directory domain controller, an Exchange 2010 server, a Windows 2008 terminal server and a VMware ESXi host in a D2D2T scheme with daily incremental and weekly full backups. All pretty standard, I'd think.

Every once in a while, one or more of the disk to tape duplication jobs fail with the error message:

Fehlerkategorie   : Auftragsfehler
Fehler            : e0008105 - Ungültiger Identifikator für die Medien des Wechslers der physischen Datenträger.

Zusätzliche Informationen zu diesem Fehler finden Sie unter der Verknüpfung V-79-57344-33029

Translation:

"Error category: Job error

Error: e0008105 - Invalid Physical Volume Library Media Identifier

You'll find additional information about this error under the link V-79-57322-33029"

The German-looking error message is, to me as a German native speaker, completely unintelligible. Following the link promising "additional information" leads to a knowledge base search revealing the original English message above (which doesn't actually tell me much, either) and offering a few articles claiming that the problem should be fixed in Service Pack 2.

There is no discernible rule which duplication jobs succeed and which ones fail. Last night, for example, the Exchange job failed while all others succeeded. Yesterday, the Exchange job succeeded but the VMware jobs failed.

What is the meaning of that message and what can I do to avoid it?

Thanks,

Tilman

[lmosla]

Are these all GRT enabled jobs? 

Also, do you see any errors in Windows event logs durring the times of the job failures?

[Artegic]

The jobs are all GRT enabled.

The only errors in the backup server's event log are the messages from Backup Exec reporting the failed jobs (Event ID 34113, Source Backup Exec), and of course the inevitable TerminalService complaints about missing printer drivers whenever I log in via RDP.

[Artegic]

Last night, all jobs completed successfully without producing the mysterious "invalid identifier" error.

The two nights before, the same job failed in a row.

Still no discernible rule or reason.

What can I do?

[lmosla]

Since this was addressed with service pack 2, try repushing the agent out to your remote servers.

Are you using Symantec drivers for the tape device? 

also have you tried recreating the duplicate jobs?

Make sure any antivirus scans are excluded from the Backup Exec processes.

[Artegic]

Repushing the agents proved a major hassle, leading to an unplanned downtime for rebooting all involved servers. Since then the problem hasn't reappeared. I hope it'll stay that way.

[Artegic]

Problem hasn't reappeared. I'm marking this solved.

Thanks,

Tilman

[Artegic]

Seems I spoke too soon. Regrettably, the problem has reoccurred today.

[Artegic]

A few additional data points, in the hope of somewhat reducing the perceived randomness:

- Of the nine backup jobs I have (four Windows servers, one Linux server, and four sets of VMs, all on the same ESXi host), only two have exhibited the error so far.

- Only GRT enabled jobs exhibit the error. This excludes the Linux server and two of the VM sets (those comprising Linux VMs.)

- Only D2D2T jobs exhibit the error. This excludes two of the Windows servers and another one of the VM sets, which are backed up directly to tape without a disk stage.

- Of the remaining three jobs, two have exhibited the error at various times, with no discernible correlation between them: one backing up an Exchange server,  the other a set of Windows VMs on the ESXi host.

- The remaining one, which also never exhibited the error so far, is the self backup of the Backup Exec server itself.

- Another notable difference: the two jobs exhibiting the error use deduplication storage for their disk stage, while the self backup job uses plain disk storage.

- The error has so far only appeared on incremental job runs, never on full ones.

- Whenever the error appeared on an incremental run, it also appeared on all subsequent incremental runs until the next full backup. In most cases, after a full backup the next couple of incremental ones succeeded.

Still no information at all on what that error message actually tries to tell me. What is a Physical Volume Library Media Identifier? Where did the invalid one come from? What was it supposed to identify? In what sense is it invalid? What does the Media GUID included in the job log refer to? Is there a way to look it up somewhere?

[Artegic · Accepted solution]

Following the discussion in https://www-secure.symantec.com/connect/forums/incremental-backup-based-wrong-full-backup I have now reorganized all my D2D2T jobs so that the monthly off-site backups are not performed as independent full backups, but as copies of the last regular (ie. non-off-site) full backup. The "Invalid Physical Volume Library Media Identifier" error has not reoccurred since. I can only speculate that it really referred (without actually saying so) to the volume containing the off-site backup on which it wrongly tried to base the incremental.