Video Screencast Help

Cant restore from dedupe: Final Error: 0xe0008105

Created: 10 Feb 2014 • Updated: 11 Feb 2014 | 8 comments
This issue has been solved. See solution.

One of our sattelite offices storage went down and we are trying to restore from backup.  We are using deduplication and storing the data onto a NAS device.  I have an open case with Symantec and have been trying to get this resolved over the past 18hrs, but we aren't having luck.

Server: Windows 2008 R2
SBE: 2012 (all updates)

Our SBE is a VM on Hyper-v 2012 with iSCSI attached storage to host the deduplication storage.  We are backing up the Shadow Copy Components and so we are restoring with this option.  But when we do we get the following:

When trying to restore from a backup but we are getting the following errors:
V-79-57344-33029 - Error - Mount Failed
Invalid Physical Volume Library Media Identifier.

V-79-57344-33029 - Unable to acquire device for the specified pool and media
Invalid Physical Volume Library Media Identifier

Under Job Completion Status:
Final Error: 0Xe0008105

Symantec support is scratching their head at this.  We've been at it for over 20hrs.  I need help and sleep!

Operating Systems:

Comments 8 CommentsJump to latest comment

pkh's picture

Using a virtualised media server to access real devices is not a supported configuration.

Larry Fine's picture

I see they are using iSCSI disk for dedupe.  What are you believing is unsupported?

If you find this is a solution for the thread, please mark it as such.

pkh's picture

It has been stated many a times by Colin Weaver that accessing real devices from a virtualised media server is not supported.  He did not make an exception for iSCSI disks.  As with all unsupported configuration, if it works, the user is lucky.

If you say that accessing iSCSI disks from a virtualised media server is supported, do provide the supporting documentation from Symantec.

Larry Fine's picture

From the BE 2012 HCL:

Configuring a tape device with a virtual machine is considered an "Alternative Configuration".


Using a tape backup device attached to a virtual machine through the SCSI pass-through mechanism is considered an Alternative Configuration.

If you find this is a solution for the thread, please mark it as such.

pkh's picture

An alternative configuration means that it is not supported. You have to prove that the problem exists with a physical server before Symantec will take a look at it. In any case, what you have quoted is for tape devices, not iSCSI disks

Furthermore your reference are for VMware and not for Hyper-V

Larry Fine's picture

From the BE 2012 HCL:

For this basic support, any device recognized and supported by the Windows platform should work with Backup Exec.

I consider it to be supported as there is nothing that says it isn't supported.  I can only assume that tech support also considered it supported as the OP stated that tech support had spent many hours with him, tech support never told him it was unsupported, and the solution to the issue was apparently a credential issue (which has nothing to do with the hardware).

If you find this is a solution for the thread, please mark it as such.

pkh's picture

The help could be extended on a best effort basis.

If you are using that statement as a basis of support then there is no need for an elaborate HCL.  That statement pretty much covers everything.  In case you are not aware, this statement is for disks connected to a physical media server, NOT to a virtualised media server.

Regarding accessing tape drives from VMware VM's, VMware has stopped supporting such configuration from ESX 5.x.  See this document

Anyway, you are entitled to your opinion.  The ultimate proof will be at crunch time when you need support and is refused.

Atur S.'s picture

Yeah I don't understand that either.  We've had this configuration for a long time.  It works and support has never had an issue with our configuration.  

After spending much time with support we found an issue with the System Logon account.  They guided me into replacing it with an active admin account.  We also ran Inventory and Catalog on the storage.  This took a long time for our 4tb data storage.  About 15hrs.  But in the end I was able to start recovering our data.  If I were to setup our data storage again I would try to seperate our data into 2-3 storage devices.  This will lessen recovery times when something bad happens with the storage.  Hopefully this will be our last issue with Symantec.  We're moving on to another product.