Standby VM Fails to Export After 6.3 Upgrade.

Question

My first backup and export cycles after upgrading to 6.3 failed with the following messages- 
 Error 
 One or more dependent export tasks have failed. TevoGetFlagsInOfflineVolume failed with error -2147024893 (0x80070003 - The system cannot find the path specified) 
 Server side: 
 Replay.Core.Contracts.Export.ExportException: One or more dependent export tasks have failed. ---> System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> Replay.Common.Contracts.TevoLib.TevoLibraryErrorException: TevoGetFlagsInOfflineVolume failed with error -2147024893 (0x80070003 - The system cannot find the path specified) at Replay.Common.NativeWrapper.TevoLib.TevoLibraryErrorException.Throw(String functionName, Int32 errorCode) at Replay.Common.NativeWrapper.TevoLib.TevoLibWrapper.GetFlagsInOfflineVolume(String mountPoint) at Replay.Common.Implementation.Virtualization.P2VPostprocessor.UpdateMetadataFile(String mountPoint, Guid driverId, FileSystemType fileSystemType, UInt32 restoredEpochNumber, UInt32 highestEpochNumber) at Replay.Core.Implementation.Export.VirtualMachineExporterWindows.UpdateMetadataFile(IVolumeImage volumeImage, String mountPoint) at Replay.Core.Implementation.Export.VirtualMachineExporterWindows.TryPostProcessVolume(IPAddress replayServerAddress, IVolumeImage volumeImage, ExporterSourceVolume exporterSourceVolume, MountFlags mountFlags) at Replay.Core.Implementation.Export.VirtualMachineExporterWindows.PostProcessExportedVolume(ExporterSourceVolume exporterSourceVolume, IPAddress replayServerAddress) 
 --- End of inner exception stack trace --- --- End of inner exception stack trace --- --- End of inner exception stack trace --- at Replay.Core.Implementation.Export.ExportJob.ExportTask() at System.Threading.Tasks.Task.Execute() 
 Replay.Common.Contracts.TevoLib.TevoLibraryErrorException: TevoGetFlagsInOfflineVolume failed with error -2147024893 (0x80070003 - The system cannot find the path specified) at Replay.Common.NativeWrapper.TevoLib.TevoLibraryErrorException.Throw(String functionName, Int32 errorCode) at Replay.Common.NativeWrapper.TevoLib.TevoLibWrapper.GetFlagsInOfflineVolume(String mountPoint) at Replay.Common.Implementation.Virtualization.P2VPostprocessor.UpdateMetadataFile(String mountPoint, Guid driverId, FileSystemType fileSystemType, UInt32 restoredEpochNumber, UInt32 highestEpochNumber) at Replay.Core.Implementation.Export.VirtualMachineExporterWindows.UpdateMetadataFile(IVolumeImage volumeImage, String mountPoint) at Replay.Core.Implementation.Export.VirtualMachineExporterWindows.TryPostProcessVolume(IPAddress replayServerAddress, IVolumeImage volumeImage, ExporterSourceVolume exporterSourceVolume, MountFlags mountFlags) at Replay.Core.Implementation.Export.VirtualMachineExporterWindows.PostProcessExportedVolume(ExporterSourceVolume exporterSourceVolume, IPAddress replayServerAddress)

Tim Seymour · Accepted Answer

Yes, if it won't mount, you need a new RP chain. 
 When you upgraded, what specifically did you upgrade? The core? The agent? What build did you upgrade from on each? 
 If you downgrade the agent you have to uninstall and reinstall the old version. That will force a new base image. So downgrading the agent doesn't save you anything. Besides, once the RP chain has an issue like this the safest thing to do is start a new RP chain. 
 Downgrade of the core is not supported and in the one or two times I've done it in the lab has had very mixed results, most of which involved lots of errors on jobs that use the recovery points (integrity check of RPs, mountability, attachability, rollup, etc.). So definitely do NOT downgrade the core unless you want to start over on everything. 
 So I'd say downgrade is not an option in any way. 
 To get a new RP chain, take a base image of any volumes that you can't browse. If you have a big data volume and it is healthy, just change the schedule on the OS volume so that it is no longer grouped with the big data volume and force a new base on just the OS volume. Then change the schedule back. That way you only have to base the OS volume. That should speed up the process of remediation. Just make sure you set the schedule back so that everything is backing up at the same time so that your exports are complete when they run.

Standby VM Fails to Export After 6.3 Upgrade.

Top Replies