Comprehensive data protection for all workloads
Post Reply
rspencer
Lurker
Posts: 2
Liked: never
Joined: Feb 24, 2015 8:43 pm
Full Name: Robert Spencer
Contact:

Replicating SQL .BAK files

Post by rspencer » Jun 19, 2015 2:08 pm

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
Veeam Software
Posts: 7001
Liked: 717 times
Joined: May 21, 2014 11:03 am
Full Name: Nikita Shestakov
Location: Prague
Contact:

Re: Replicating SQL .BAK files

Post by Shestakov » Jun 19, 2015 4:21 pm

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
Product Manager
Posts: 17000
Liked: 1455 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Replicating SQL .BAK files

Post by veremin » Jun 22, 2015 10:07 am

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
Lurker
Posts: 2
Liked: never
Joined: Feb 24, 2015 8:43 pm
Full Name: Robert Spencer
Contact:

Re: Replicating SQL .BAK files

Post by rspencer » Jun 24, 2015 12:56 pm

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.

Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot], Wintermute and 61 guests