-
- Expert
- Posts: 205
- Liked: 17 times
- Joined: Nov 12, 2014 9:40 am
- Full Name: John Johnson
- Contact:
improving DR configuration
Hi all,
We have two hyper-v clusters separated by 50ms latency on a 225 mbit link (we can burst above this but one farm is on 95th percentile billing).
Production has 3 nodes, DR has 2 nodes. Both have a shared SAS production array and a second shared SAS array for veeam backups.
We have two veeam 9.5 servers each licensed for a single host. Currently both veeam servers are in the DR site.
We back up one Exchange DAG node in each site, and file servers and skype servers and web servers in the production site.
We replicate file servers to the DR site as well as a few other servers.
In the DR site we back up some utility servers as well as the replicas.
The last part is what I'm unsure of. Since we are backing up replicas, CBT cannot be used. I wish there was a way to have zero snapshots set on replicas (we have the lowest offered, which is one) so that avhdx files would not be used at all.
Perhaps there is a better way to approach this? I like having completely independent backups at each site vs. simply doing a copy job, but maybe that's how we should be reworking things, and not back up the replicas at all (rather, build the replicas from the local copy job)?
We have two hyper-v clusters separated by 50ms latency on a 225 mbit link (we can burst above this but one farm is on 95th percentile billing).
Production has 3 nodes, DR has 2 nodes. Both have a shared SAS production array and a second shared SAS array for veeam backups.
We have two veeam 9.5 servers each licensed for a single host. Currently both veeam servers are in the DR site.
We back up one Exchange DAG node in each site, and file servers and skype servers and web servers in the production site.
We replicate file servers to the DR site as well as a few other servers.
In the DR site we back up some utility servers as well as the replicas.
The last part is what I'm unsure of. Since we are backing up replicas, CBT cannot be used. I wish there was a way to have zero snapshots set on replicas (we have the lowest offered, which is one) so that avhdx files would not be used at all.
Perhaps there is a better way to approach this? I like having completely independent backups at each site vs. simply doing a copy job, but maybe that's how we should be reworking things, and not back up the replicas at all (rather, build the replicas from the local copy job)?
-
- Product Manager
- Posts: 6408
- Liked: 724 times
- Joined: May 19, 2015 1:46 pm
- Contact:
Re: improving DR configuration
That holds true for VMware. With Hyper-V it's OK to backup replica using CBT. Does that help?Since we are backing up replicas, CBT cannot be used.
May I ask you what's wrong with doing a copy job? It was specifically designed to transfer your backups in a safe and reliable manner.I like having completely independent backups at each site vs. simply doing a copy job
That should work too.rather, build the replicas from the local copy job)?
Thanks
-
- Expert
- Posts: 205
- Liked: 17 times
- Joined: Nov 12, 2014 9:40 am
- Full Name: John Johnson
- Contact:
Re: improving DR configuration
CBT does not function on the replicas. We get the "cannot use CBT" warning and the backup takes hours as it runs through the full disk.
If we do a copy job, then we are dependent on the production backups vs having two fully independent backup chains.
If we do a copy job, then we are dependent on the production backups vs having two fully independent backup chains.
-
- Product Manager
- Posts: 6408
- Liked: 724 times
- Joined: May 19, 2015 1:46 pm
- Contact:
Re: improving DR configuration
I suspect that is not related to the fact that you are taking backup of a replica. Please check this KB article and follow all the steps mentioned there to troubleshoot CBT.We get the "cannot use CBT" warning and the backup takes hours as it runs through the full disk.
What do you mean by "dependent"? Backup copy chains can be used separately from the main chain.then we are dependent on the production backups
Thank you
-
- Expert
- Posts: 205
- Liked: 17 times
- Joined: Nov 12, 2014 9:40 am
- Full Name: John Johnson
- Contact:
Re: improving DR configuration
Pretty sure it is related to backing up a replica. Had a prior support case on this.
-
- Product Manager
- Posts: 6408
- Liked: 724 times
- Joined: May 19, 2015 1:46 pm
- Contact:
Re: improving DR configuration
Could you post the case ID for reference please?Had a prior support case on this.
Thanks
-
- Expert
- Posts: 205
- Liked: 17 times
- Joined: Nov 12, 2014 9:40 am
- Full Name: John Johnson
- Contact:
Re: improving DR configuration
I think it’s 02271491 but not positive
-
- Expert
- Posts: 205
- Liked: 17 times
- Joined: Nov 12, 2014 9:40 am
- Full Name: John Johnson
- Contact:
Re: improving DR configuration
Hi, any thoughts? We are still getting
Cannot use CBT: There is no change tracking data available associated with the specified change tracking identifier.. Failed to query changes for disk 'C:\ClusterStorage\Volume1\FILES1-REP\7B0AC05F93E246FEB7A0F82F2B9F3036(1)\SCSI0-3\FILES1-M_35D4D74A-9A77-4BB6-B130-4C312E646061.AVHDX'
for all our disks and out of 1.6 TB, 1.3 TB gets read and the backup takes 4.5 hours. With CBT this would be a lot faster, no?
Cannot use CBT: There is no change tracking data available associated with the specified change tracking identifier.. Failed to query changes for disk 'C:\ClusterStorage\Volume1\FILES1-REP\7B0AC05F93E246FEB7A0F82F2B9F3036(1)\SCSI0-3\FILES1-M_35D4D74A-9A77-4BB6-B130-4C312E646061.AVHDX'
for all our disks and out of 1.6 TB, 1.3 TB gets read and the backup takes 4.5 hours. With CBT this would be a lot faster, no?
-
- Product Manager
- Posts: 6408
- Liked: 724 times
- Joined: May 19, 2015 1:46 pm
- Contact:
Re: improving DR configuration
Hi,
Sorry for the delay. So, indeed, you're right - CBT does not work if you're backing up replicas. Then the only way to get things going faster would be to do it the other way around - start doing remote replicas from local backup copy job files so CBT can be utilized. Before we go any further please correct me if I'm wrong:
1. VBR-1 (on the DR site) manages backups that hit PROD local storage and also manages replicas going from PROD to DR.
1. VBR-2 (on the DR site) manages backup jobs happening on the DR, including those of replicas.
Is that correct?
Also, what do you mean by "dependent"? Backup copy chains can be used separately from the main chain. In case of doing backups from replicas you still have a "dependant" chain as your backups depend on the replica they are based on.
Thanks
Sorry for the delay. So, indeed, you're right - CBT does not work if you're backing up replicas. Then the only way to get things going faster would be to do it the other way around - start doing remote replicas from local backup copy job files so CBT can be utilized. Before we go any further please correct me if I'm wrong:
1. VBR-1 (on the DR site) manages backups that hit PROD local storage and also manages replicas going from PROD to DR.
1. VBR-2 (on the DR site) manages backup jobs happening on the DR, including those of replicas.
Is that correct?
Also, what do you mean by "dependent"? Backup copy chains can be used separately from the main chain. In case of doing backups from replicas you still have a "dependant" chain as your backups depend on the replica they are based on.
Thanks
Who is online
Users browsing this forum: No registered users and 25 guests