Failback to Production very slow

[mandy2022]

Case #05874081

My main question is that is it normal for virtual machine with 1.5 TB of data (SQL database) to take 4 to 6 hours to failback to production when all I did was add a folder on the desktop to test a small minor change made?

I have tested countless different ways and all result in the same failback slowness.

To give more information the initial replication of the job to the secondary site took four hours which seems acceptable. This was with no seeding and no data at the other end.
The replications after that took on average 7 minutes, replications occur every hour.
The failover to the secondary site was instant pretty much. Re IP rule in place and did a manual failover, not planned.
Next I logged into the sql server and added a folder on the desktop. Then failed back over right away. I had quick roll back checked off and faiiled back over to the original VM. Each time this took 4 to six hours.
No other veeam jobs are running during this time and.

I've tried different proxy's. Physica server for the proxy server, I tried a virtual server - hot add, virtual server . direct SAN. network mode. All resuls were slow.

Each site has a 10 GB network, vmxnet3. ISCSI network. The connection between the two sites through the router is 1GB but eveerything inside both sites from switch to esxi hosts, nimble array, physical servers is 10 GB.

Going back to question is this normal for a failback to production for this size of data with no changes? Is there a better way for me to move back to production then using this failback feature? Is there something I'm missing here or doing wrong or should I just give up and accept this is what is expected?

[Gostev]

How did you determine "no changes"? In general, SQL Server is extremely "chatty" as it comes to the disk I/O. While you may have only added a small file, it does not mean SQL Server did not do tons of disk changes on its own from just starting all databases up. For a clean experiment, you should disable SQL Server prior to taking a backup, so that you're powering on a machine without it running. Even then, the OS boot process will still make a significant number of disk changes (registry, logs etc.) of at least a few hundred MBs worth.

[mandy2022]

Hi, yes I can try that and report back. So I guess I have to first disable the sql services on the production VM. Then do a final replication like that to the secondary site. Then I'll fail over to the other site and not even turn on the replica and immediately fail back over to prod.

I also have a file server that is about 1.5 TB , no databases on it that I could test with as well. I haven't tried that one yet.