Backup Exec 2014 cannot restore its Hyper-V backups? 0x1d error

[RR7]

Hi,

been running with a trial of BE2014, backups reported to be running fine, now had a VM host failure and need to restore a Hyper-V client from Tape.

i can run a catalog and see the files but i cannot either restore a whole VHDX or files from within. i get the same error, 0x1d cannot write to the specified device. it creates 0byte VHDX files in the locations. the same thing happes when doing a redirect to another drive.

i also tried setting up a B2D on usb drive and doing a duplicate of the tape archive, but the same error occurs. it doesnt matter which VM i try and restore, the same thing hapens. i CAN restore backups from the c drive of the host, back onto the host. but the VHDX files do not appear here.

all i really need is to pull the VHDX files off,i dont need any fancy restore features.

so, what am i doing wrong? or does BE2014 simply not work properly?

[Steve-Young]

In your restore selection for the host do you see the VHDX file?

The steps below apply to virtual machines that were backed up through the
virtual host with the Agent for Hyper-V

To restore the entire virtual machine or
virtual disks

Do the following in the order listed:
¡ In the Details pane at the bottom of the
screen, select the virtual machine.
¡ Click Restore, and then select Restore
virtual machine from the host.
¡ In the Restore Wizard, select Hyper-V
data, and then click Next.
 

The restore of a Microsoft Hyper-V virtual machine that is created within a mount
point fails if the mount point does not exist at the time of the restore. To avoid
this issue, configure the virtual machine to use volume GUID paths with no
mount points.

If you are restoring from Tape make sure the temporary staging location is set to a valid disk (not usb).

[RR7]

Hi, thanks for the reply.

if i view the hosts backup set, and choose the restore files, folders or volumes option,  there is no VHDX in the folders.

however, it does give me the option to restore Microsoft Hyper-V Data, and the VHDX files appear here, and the above result occurs.

the staging location, according to Granular Recovery Technology Options, is C:\TEMP and there is 1.5TB free 3 times more space then the backup size)

i did read the instruction on the administrators guide you have quoted. nothing appears in the details pane. the host had to be installed from scratch, then BE installed to the host, then inventory and catalogue of the tape.

the 0x1d error isnt giving me much to go on, is there a more verbose log?

[RR7]

i did reply but it seems to have vaished, apologies if this gets double posted...

i see the VHDX if i chose to restore Microsoft Hyper-V data, but not files, folders or volumes. that seems normal to me.

i have too read the admin guide that the above is quoted from, but there is nothing in the details section, i guess becuase i am restoring to a new host and the previous one died. that is to say, fresh install of windows, fresh install of BE, invetory and catlogue of tape. then restore.

the GRT staging folder is the default C:\TEMP and there is plenty of space there (1.5TB)

[RR7]

i'm going to go out on a limb here and suggest that BE2014 doesn't work properly. which is a shame since i had a failure and despite reports of successful backups, it seems unable to restore them:

i found the debug program on the cd. so i ran it, looks like BEREMOTE.EXE is whats trying to write the file.

the only debug info relating to that is interesting, as it says:

BEREMOTE: [06/30/14 22:09:56] [4320]     [fsys\vrtsrv]        - VirtualServer::WriteRedirectionIsNecessary: name 'C:\Users\Public\Documents\Hyper-V\Virtual hard disks\SBS-SERVER1\SBS-SERVER1-0.vhdx' strm.id HPFO chainIndex 0 maxElements 0 openExisting 0
BEREMOTE: [06/30/14 22:09:56] [4320]     [fsys\vrtsrv]        - VirtualServer::WriteRedirectionIsNecessary: about to create VHD 'C:\Users\Public\Documents\Hyper-V\Virtual hard disks\SBS-SERVER1\SBS-SERVER1-0.vhdx'
BEREMOTE: [06/30/14 22:09:56] [4320]                          - bevs::IVhdFileUtil::create_VHDX_from_handle: invalid virtual disk size 2145288192
BEREMOTE: [06/30/14 22:09:56] [4320]     bevs::IVhdFileUtil::create_VHDX_from_handle: invalid virtual disk size 2145288192
BEREMOTE: [06/30/14 22:09:56] [4320]     [fsys\vrtsrv]        - VirtualServer::WriteRedirectionIsNecessary: VHD created, rc: 87
BEREMOTE: [06/30/14 22:09:56] [4320]     [fsys\vrtsrv]        - VirtualServer::WriteRedirectionIsNecessary: create_VHD_from_handle failed err 87 (0x57)
BEREMOTE: [06/30/14 22:09:56] [4320]     [fsys\shadow]        - Status Unknown (0x0000001D) for FDB pass thru object 2 in SHADOW::WriteObj
BEREMOTE: [06/30/14 22:09:56] [4320]     [fsys\vrtsrv]        -   VRTSRV:Status Unknown (0x0000001D) calling FS_WriteObj in VirtualServer::WriteObj:500
BEREMOTE: [06/30/14 22:09:56] [4320]     [ndmp\loops]         - LP_ENV::MsgError: error 0x0000001d processing object C:\Users\Public\Documents\Hyper-V\Virtual hard disks\SBS-SERVER1\SBS-SERVER1-0.vhdx
BEREMOTE: [06/30/14 22:09:56] [4320]     [fsys\shadow]        - Status FS_NO_SECURITY (0x2000FFB3) for FDB pass thru object 2 in SHADOW::CloseObj

despite this early error, the tape device keeps on going as does the job for ages before failing, but during this time although scsi reads are going on, no data is being written to any drive, temp folder or otherwise.

so now i have 3 servers in limbo stuck on a backup tape and no means it seems to get them off. i'm guessing there is no way to extract the raw vhdx file off the tape directly to the HD, since it looks like BE's 'clever' staging doesnt seem to be able to create the vhdx file on the disk :(

[VJware]

Your debug seems to match the one as outlined in this KB - http://www.symantec.com/business/support/index?page=content&id=TECH218479

[RR7]

okay thats scary.

the workaround isn't a workaround for us, we cant backup anything as it went down and there was never any problem reported during the backups, the only copy we now have is on the BE2014 backup tapes.

i could stream the whole VHDX files off the tape as we're in a total loss situation and dont need any granularity, but there seems to no way to do that. is there a way to simply do that, by editing the catalog or something?

[VJware]

I have PM'd you a workaround. Let me know if it works.

[RR7]

thus far the workaround isn't applicable.

can anyone at Symantec's dev team give any idea when this is likely to be hotfixed? and if this is going to be applicable to the existing tape i'm trying to restore?

we've just gone to a data recovery company who were unable to get the data off either :(

[dfwood]

I've had the same problem and it has been identified as an issue with converted disks.

It's a waiting game now for a hotfix or service pack.