Replicating SQL .BAK files

[rspencer]

In our setup we have Veeam backing up and replicating the entire VM which includes a volume that contains native SQL backup (.bak) files for the last two days. It is configured this way because we trust the native SQL backup than third party applications as well as having an alternative means of restoration in case the restored VM results in a corrupted DB.

I would have thought with CBT that since the rate of change of the 1's and 0's isn't significant that the replication after the first time would complete quicker. The original replication of this one volume took 66 hours, the next one is up to 36 hours and still has a ways to go.

I am curious to know if others experience this same issue and if so do you just live with it or did you figure out a way to resolve it? Did you find whether compressed or uncompressed native SQL backups made any difference?

[Shestakov]

Hello Robert,
Since CBT works with datablocks, the change of the single bit implies the change of the whole data block, thus the whole block is to be copied.
The workaround here is to shorten the size of data blocks.
Thanks!

[veremin]

What is the major bottleneck identified in the job statistics? Also, haven't you thought about pointing SQL to disk that might be excluded from processing (independent, shared, etc.)?

[rspencer]

What is the major bottleneck identified in the job statistics?

Throttling. I take that with a grain of salt because the job runs so long with this volume attached it will naturally slow down during business hours when throttling is enabled. There are 4 other volumes that the total size is approximately 700 GB that completes in 4-5 hours while 2 other replication jobs are running. It is this one 500GB volume with the SQL native backups that takes 50-60 hours

Also, haven't you thought about pointing SQL to disk that might be excluded from processing (independent, shared, etc.)

Yes. That is what I am currently doing but I do not agree with not having the .bak files replicated. I would be more comfortable knowing the sql native backup is available in the target in case there was DB corruption during the replication.