Azure Site Recovery Migration - Cant replicate one drive on server

Question

AWS box migrating to Azure via ASR. Getting the following errors from vcap. Can someone point me in the right direction?

Using replication appliance that has successfully replicated numerous other VM's however have had churn issues previously with this one on this same drive that wont replicate..
We moved it across to needing a premium disk for this drive I am now getting an error saying the Replication cannot accept any more data from the disk.
Looking on the server in question, in earlier logs for vacp found erros around "One or more disk in IR/resync - skipping consistency."
However now I am finding that it is regularly crashing with a crash log of:
Elapsed Time for TagIoctl is 0
Elapsed Time for all driver phases is 0
Command Line: "C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\vacp.exe" -systemlevel -parallel -vtoa -cc
Exiting with status 0
Generating Header for TagGuid: b190c1c4-af63-437e-8d96-5cb3959ea178
InternallyRescheduled 0
Issued a LOCAL TAG
SysTimeKey 1668142568
Tag is inserted for 3
Tag: CrashTag636dd5e8
Tag: SystemLevelTag636dd5e8
Tag: _desc:Disk=4,Dyn=0,atapi=0,dhcp=2,intelide=0,san=2,storflt=0,storvsc=0,vmbus=0
TagInsertTime: 1668142568
TagType CRASH
VacpEndTime 1668142568
VacpStartTime 1668142568

and reporting a :regular error in event logs from InDiskFit Error ID: 20033
Diff Sync Throttle started for disk 0 (ID = 967774476) StartTimestamp 133126163784079919.
This is occurring once every minute.

We have ensured we are running the latest version of mobility client and the latest version of ASR on the replication appliance and restarted both servers since.
We have run a chkdsk on the drive in question on the server to be replicated and no errors with only using under half capacity on a 120GB hard drive.

Can someone assist with what else we can look into from here as I am out of troubleshooting guides online due to the replication server reporting healthy and all checks on the VM and replication server looks fine.

Answer 1

Hi @Luke Prouse Sorry for the inconvenience this must have caused you.

The error skipping/failed consistency indicates that these errors are occurring due to failures while attempting to generate VSS snapshots.

On Windows servers, often times this can happen due to applications such as SQL or third party backup software attempting to generate VSS snapshots and failing/resulting in a clash with ASR's attempts to generate an application consistent snapshot.

You can find out if this is being caused due to a specific application/writer by running the following command from command prompt on the virtual machine on which this problem is being seen

"VSSadmin.exe list writers"

If the output of this command indicates failure for one particular writer, it is probably that application that is causing the VSS snapshots to fail. In such a case, most likely you'll be able to remediate this problem by restarting the service associated with the VSS writer that is failing.

If all the writers are in a healthy/stable state, try restarting the following services from services.msc

• Volume Shadow Copy
• Azure Site Recovery VSS Provider

Wait for a couple of hours once this is done to see if App-consistent snapshots are being generated successfully

Rebooting the VM as it is another way to achieve what I've described here.

If you aren't interested in generating app-consistent recovery points for this virtual machine, you can change the app-consistent snapshot frequency in the replication policy to 0. Please not this will impact all virtual machines using this replication policy and ASR will stop attempting to generate app-consistent recovery points for virtual machines using this policy (ASR will then generate only crash consistent recovery points for these virtual machines)

Hope this helps. Please tag me in your reply if you need further assistance!

----------------------------------------------------------------------------------------------------------------------

If the response helped, do "Accept Answer" and up-vote it

Answer 2

Can confirm that server is now replicating without issue.
the 2 main issues were:
NAT appliance in AWS was set too low spec and outgoing traffic was being slowed down and causing some errors across servers when replicating, however wasnt stopping them from replicating, just took longer.
Primary reason for this server, was an ETL file that had data being written to it for network tracing and caused churn on that disk to be too high on that drive and stopped the replication process from completing.