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?
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Feb 24, 2015 8:43 pm
- Full Name: Robert Spencer
- Contact:
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Replicating SQL .BAK files
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!
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!
-
- Product Manager
- Posts: 20402
- Liked: 2298 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Replicating SQL .BAK files
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.)?
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Feb 24, 2015 8:43 pm
- Full Name: Robert Spencer
- Contact:
Re: Replicating SQL .BAK files
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 hoursWhat is the major bottleneck identified in the job statistics?
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.Also, haven't you thought about pointing SQL to disk that might be excluded from processing (independent, shared, etc.)
Who is online
Users browsing this forum: efd121, Semrush [Bot], veremin and 154 guests