cancel
Showing results for 
Search instead for 
Did you mean: 

Copy to tape failing with error 0xe0009585 after backup to disk ran fine

Artegic
Level 6

I have Backup Exec 2012 with all current patches running on Windows Server 2008 backing up several Windows and Linux VMs from a VMware ESXi 5.0 host in a D2D2T scheme with daily incremental and weekly full backups. GRT is enabled for the Windows VMs.

Most of the VMs are backed up without problems. For one Windows 7 VM, however, the tape copy job after the daily incremental backup reports the following error every time (translated from German):

Final error: 0xe0009585 - Unable to open a disk of the virtual machine.
Final error category: Resource error

You'll find additional information on this error at the link V-79-57344-38277
http://entced.symantec.com/entt?product=BE&version=14.0.1798.1300&module=eng-no_fs-base_task&error=V-79-57344-38277&language=EN&build=Retail&os=Windows

Copy
V-79-57344-38277 - Unable to open a disk of the virtual machine.

- WARNING: "VMVCB::\\uranus\VCGuestVm\(DC)ha-datacenter(DC)\vm\rds - Win7 Prof.\rds - Win7 Prof.\Windows 7 Prof..vmdk" is damaged. File check not possible.

The incremental backup to disk itself runs fine; its only the subsequent copy to tape that fails. (Leaving me wondering why that copy job needs to open the disk of the virtual machine at all.) Also, the copy job after the weekly full backup runs without an error; it's only the copy job after the incremental that fails. (Leaving me wondering why the virtual disk is damaged on weekdays but ok on weekends.)

The link V-79-57344-38277 produces offers four tech articles: one referring to a restore problem; two referring to an error message I do not get ("You do not have access rights to this file."); and one describing a problem that was fixed with Hotfix 199866 which I have installed already.

A KB search turned up article TECH198982 which seems to fit my symptoms but identifies no cause and as only solution proposes to install Service Pack 3 which I have installed already. All other hits either refer to the "no access rights" message above, or to restore, or describe scenarios that would affect backups of all VMs, not just one of them.

Ideas?

Thanks,

Tilman

20 REPLIES 20

Artegic
Level 6

I have now renamed the VMDK file so that it doesn't contain a double dot anymore. This required following a rather convoluted procedure and entailed a lengthy downtime for the VM, but solved the problem.