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

Another update: The error V-79-57344-34009 actually prevented the failing VM "rds - Win7 Prof." from being backed up to disk in the first place, so it's unsurprising in hindsight that it wouldn't trigger the error in the subsequent copy to tape stage anymore.

Now with the next regular full backup, the error V-79-57344-34009 has gone away, and V-79-57344-38277 is back.

I have now captured a SGMon log from a failing copy job. It covers an interval of 8:30 mins and is 40 MB in size. The actual job ran for 7:13 mins. Neither "V-79-57344-38277" nor "E0009585" appear in the log literally, but a search for "9585" revealed this block of messages:

BEREMOTE: [02.05.14 11:05:55] [8136]     2014-02-05T11:05:55.118 [fsys\shared]        - vddkWrapper::FindMatchingDisk FindFirstFile failed for \\.pdvfs\GOLGI\2\BEData\STHVMDK\IMG001235\Windows 7 Prof.*.vmdk. Windows Error = 2
BEREMOTE: [02.05.14 11:05:55] [8136]     2014-02-05T11:05:55.118 [fsys\shared]        - vddkWrapper::VixDiskLib_OpenLocal: FindMatchingDisk returned empty string. Disk, = \\.pdvfs\GOLGI\2\BEData\STHVMDK\IMG001242\Windows 7 Prof..vmdk, ancestor location = \\.pdvfs\GOLGI\2\BEData\STHVMDK\IMG001235
BEREMOTE: [02.05.14 11:05:55] [8136]     2014-02-05T11:05:55.118 [fsys\vmvcb\pdi]     - Could not open the local disk \\.pdvfs\GOLGI\2\BEData\STHVMDK\IMG001242\Windows 7 Prof..vmdk. Error Text: 'Invalid disk chain: cannot mix hosted and managed style disks in the same chain' Error: '16030'
BEREMOTE: [02.05.14 11:05:55] [8136]     2014-02-05T11:05:55.119 [ndmp\loops]         - LP_ENV::MsgError: error 0xe0009585 processing object rds - Win7 Prof.\Windows 7 Prof..vmdk

Again, this happens reproducibly, only on the copy to tape stage of an incremental backup, and only for this single VM. Copies of three other VMs included in the same job work fine. The preceding backup to disk stage completed without errors or warnings for all four VMs. For full backup runs of the same job, both backup to disk and copy to tape complete without errors or warnings.

Ideas?

Thanks,
Tilman

I tried opening a support case for this last Friday but only got an automated E-mail answer: "We received your request and are working to grant you access to view and manage your support cases." Since then, nothing. Even tried a second time, with the same result. The two case numbers, 05992961 and 05993223, don't even appear on our account in the support portal so far. I guess I'll have to use the phone again.

The case has now appeared in the support portal, and I got an E-mail from a support technician saying:

I would really appreciate if you could provide me with an update on the status of this issue.

Which left me a bit baffled. What kind of status update am I supposed to provide on a case where nothing has happened yet? I tried to call back but was told by the call management system that the person handling the case was unavailable. I guess it will take some time before I'll get anywhere there.

Meanwhile I would still be grateful for any hints about things I could try on my own.

Things are starting to move. Today I had a WebEx session with a Symantec support engineer, who noticed that the issue involved virtualization and should consequently be reassigned to the VM team. Obviously he couldn't trust my problem description which said exactly that, and had to see it with his own eyes.

I do hope that reassignment will now lead to some actual progress.

Update: After many WebEx sessions with an engineer from the VM team the case has been escalated. Now going through everything once again with the new engineer. No sign of a solution so far.

Update: Last week I installed the recently released Service Pack 4. No improvement, the error occurs as before.

Update: According to the last support engineer I spoke to the problem has been reproduced in the lab now (a mere two months after I opened the case) and it is now confirmed that the problem is caused by the name of the VMDK file "Windows 7 Prof..vmdk" having two dots in a row before the VMDK extension.

(The other VM I have with a name ending on a dot had originally been created as a copy of another VM so its VMDK file is named like "Windows 7 Prof._1.vmdk" which doesn't trigger the problem.)

Technote TECH216480 has been created for the case.

The workaround hinted at in the technote is to first duplicate the backup from the deduplication storage to a separate (non-deduplication) disk storage and in a second step from there to tape. I have not tested that as it would be too complicated to set up in my environment. Instead I am backing up the affected machine directly to tape which works fine.

The jury (ie. Symantec engineering) is still out on the case.

In the meantime I have switched to backing up that VM with RAWS instead of AVVI, which also works fine. As a long term solution I plan renaming the VMDK file, but the procedure for that is rather complicated and involves a downtime for the VM, so it won't be for tomorrow.