Started getting system.timeoutexception: 'b__0' on one machine, can't tell why.

Question

One of the VM's being backed up started throwing this error every few backups since last night. Out of the past 8 backups, 5 have thrown the error. No other VM's are having this issue. These are backed up agentlessly (vCenter) direct from SAN. 
 Server side: 
 System.TimeoutException: 'b__0' for 'LS2RESDATA' has timed out at Replay.Common.Implementation.Utilities.SingletonTask.Execute(Action action, CancellationToken cancellationToken) at Replay.Core.Implementation.VSphere.EsxVirtualMachineAgentClient.PrepareForBackupOrRestoreInternal(TimeSpan takeSnapshotTimeout, TimeSpan cleanSnapshotTimeout, ShadowCopyType shadowCopyType, CancellationToken cancellationToken, Boolean isBackup) at Replay.Core.Implementation.VSphere.EsxVirtualMachineAgentClient.PrepareForBackup(TimeSpan takeSnapshotTimeout, TimeSpan cleanSnapshotTimeout, ShadowCopyType shadowCopyType, CancellationToken cancellationToken) at Replay.Core.Implementation.Transfer.TransferJobHandler.EsxTransferHandler.PrepareForBackup() at Replay.Core.Implementation.Transfer.TransferJobHandler.TransferHandler.TransferTaskInternal() at Replay.Core.Implementation.Transfer.TransferJobHandler.TransferHandler.TransferAgentTask() at Replay.Core.Implementation.Transfer.TransferJobHandler.TransferHandler.TransferTask() at System.Threading.Tasks.Task.Execute()

phuff · Accepted Answer

In a nutshell, especially if it is quiesced, it is specific to that one VM as a quiesced reaches in and takes a quest OS snapshot too - so it is indeed specific. The other thing you can do, is if you look at the time the job failed in RR, and then take that time and look at the logs on the guest OS (the event logs) under system and application, you probably have a corresponding error too. 
 As far as the 'consistent' part - this is the fun gray area of quiescing. Every other backup vendor (except ComVault) defaults to a non-quiesced snapshot, and even then you only turn it on when you want to truncate Exchange or SQL logs. That is the example for a non-quiesced snapshot is perfectly fine/adequate/safe. Simply there is no reason NOT to (other than moving part, system resources, and affecting the guest OS) take a quiesced snap, so when agent-less what put into RR they defaulted to it. If you are using RR to truncate SQL/Exchange logs, you MUST have it. If you aren't, it's a choice. A non-quiesced snap is perfectly safe, it's just the difference between if you do a backup at 8:43 your do you want to backup the data that has already been committed to the hard disk, or all the data on the disk and in RAM. A quiesced snapshot will 'flush out' RAM before the backup is taken (that is the guest level snap). Both are perfectly safe, that is why 1 is called crash consistent and the other application specific - assuming if there was a power outage and the hardware/OS was still recoverable, you'd have everything that was already written to disk, but not what was in RAM (non-quiesced). In theory everything in RAM will be committed to disk in seconds/minutes and will be included in the next backup, but there we are. 
 You also said it works some of the time, so there is probably a competing task, or VSS conflict at the time it is failing. Which would appear in the event viewer under app or system yes.

Started getting system.timeoutexception: 'b__0' on one machine, can't tell why.

Top Replies