So apologies if this has been asked before, I did do some searching on here but haven't been able to find the answer to my exact question.
Veeam: 9.5 U4
Local site: vSphere/vCenter 5.5 and 6.7 U3
Off-site: vSphere/vCenter 6.7 U3
My question is about how VMware CBT data is used when there is both a backup job and a replication job for the same VM, using 2 different Veeam servers.
Typically backup jobs are run from an on-site Veeam server/proxy/repo, and replication jobs are run from an off-site Veeam server but utilising an on-site proxy in hot-add mode for the source data, and an off-site proxy for the destination. This is because if you had a disaster at the source site, you have everything ready to go on the off-site Veeam server to failover to the replicas (as that knows about the replication jobs).
Because I don't want to risk "resetting" the CBT data being used by the local backup jobs, I have been disabling CBT in the replication jobs. I've only done this from my own logic, assuming only 1 backup server can use CBT data from the last backup it did. Is my thinking correct here?
I'm wondering if replicas have some way of using CBT data in read-only mode, like for instance being able to ignore unused thin provisioned disk etc. With CBT off, a 200GB thin provisioned disk that's only grown to 10GB will be scanned for all 200GB and take ages.
Thanks in advance
Rob
-
- Service Provider
- Posts: 118
- Liked: 10 times
- Joined: Jan 30, 2015 4:24 pm
- Full Name: Rob Perry
- Contact:
-
- Veteran
- Posts: 643
- Liked: 312 times
- Joined: Aug 04, 2019 2:57 pm
- Full Name: Harvey
- Contact:
Re: How do Backup jobs share CBT data with Replication jobs?
Hi Rob!
As I understand it, CBT is a general "pool" that all applications making calls to the API check against. Each VM has its own CTK data that you reference during your API call; in the call, you send your last recorded change ID from the previous backup. VMware's CBT should check the CTK data, find that ChangeID, and then return all changed blocks since that Change ID.
As is such, if you have multiple backups/replica operations running against the same VM, each should have its own most recent Change ID recorded, and that's how it each job gets CBT data.
As is such, when you reset CBT, all the previous ChangeIDs are useless
So I'm not sure there's a way you can do what you're hoping.
(that being said, I am doing this from memory from previous experience with VMware, but I'm pretty sure this is how it works)
As I understand it, CBT is a general "pool" that all applications making calls to the API check against. Each VM has its own CTK data that you reference during your API call; in the call, you send your last recorded change ID from the previous backup. VMware's CBT should check the CTK data, find that ChangeID, and then return all changed blocks since that Change ID.
As is such, if you have multiple backups/replica operations running against the same VM, each should have its own most recent Change ID recorded, and that's how it each job gets CBT data.
As is such, when you reset CBT, all the previous ChangeIDs are useless
So I'm not sure there's a way you can do what you're hoping.
(that being said, I am doing this from memory from previous experience with VMware, but I'm pretty sure this is how it works)
-
- VP, Product Management
- Posts: 27377
- Liked: 2800 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: How do Backup jobs share CBT data with Replication jobs?
Hi Rob,
Your question is covered in the FAQ over here > Changed Block Tracking (CBT)
@soncscy is absolutely correct on how it works.
Thanks!
Your question is covered in the FAQ over here > Changed Block Tracking (CBT)
@soncscy is absolutely correct on how it works.
Thanks!
-
- Service Provider
- Posts: 118
- Liked: 10 times
- Joined: Jan 30, 2015 4:24 pm
- Full Name: Rob Perry
- Contact:
Re: How do Backup jobs share CBT data with Replication jobs?
Thanks guys. Just for the record sonscsy I'm not wanting to reset the CBT data, just hoping to avoid vmware doing it itself (as I thought it would with 2 jobs running from different Veeam servers).
This is good news, and I also had Ivan from Veeam support reply to a ticket I opened about it with a similar answer. He explained the CTK files as more like changelogs, whereas I had imagined them as like a bitmap representing changed blocks since the last backup.
This is good news, and I also had Ivan from Veeam support reply to a ticket I opened about it with a similar answer. He explained the CTK files as more like changelogs, whereas I had imagined them as like a bitmap representing changed blocks since the last backup.
Who is online
Users browsing this forum: Bing [Bot], Majestic-12 [Bot] and 27 guests