I wanted to know if there would be a conflict between technologies if I was using different technologies while doing Image level backups. I currently have a VCB Tivoli solution in place and I am going to be implementing an Avamar solution using Image / File level backups. I have not been able to get a definitive answer regarding a conflict between the two. I believe that it should be ok but with change-block-tracking I have a slight concern.
What I would like to do is seed my backups to Avamar while continuing to provide protection using the VCB's, I have my DR solution onsite and would like to continue offsiting tapes until I get my replica grid moved. It would be beneficial to seed them while they are in the same Data Center though. Please let me know. Thanks,
Solved! Go to Solution.
I dont see a problem with this. I protect some VM's with image level as well as with guest backups. It should not matter if it a TSM client or an avmar client. You might want to ensure both are not running at the same time.
My only concern is that because it is using 2 different technologies there would be confusion as to when the last backup occurred and what will happen if this is the case.
If TSM is configured using the (now legacy) VCB interface, this will not interfere with change block tracking on Avamar. If TSM is using the VADP interface, there may be a conflict (similar to what happens if you attempt to back up Exchange or SQL using two different backup applications). I need to discuss the implications with one of my colleagues. I will get back to you as soon as I can.
I discussed with my colleague and we believe that if both applications are using change block tracking through the VADP interface, the best case is that both products would require a full backup every time. Worst case would be that the backups taken with both products would be silently corrupted. This is because the record of what blocks have changed would be flushed after each successful backup.
For example, let's say the following backups are run:
05/25 - TSM Full
05/26 - TSM Incremental (change block information erased)
05/27 - Avamar Full
05/27 - TSM Incremental (change block information erased)
05/28 - Avamar Incremental (change block information erased)
In this case, the change block information created between the Avamar full on 05/27 and the TSM incremental on 05/27 would be erased from VMware, meaning that Avamar would not know to request those changed blocks from the disk flat file so they could be backed up. It is possible that Avamar would detect that the CBT information was incorrect and force a full, though we did not have a chance to test this to confirm.
If TSM truly is using VCB (where the LUNs are mounted to the proxy and backed up from the datastore in full each day), there should not be a conflict. If TSM is using VADP and change block tracking, I would not recommend using both applications to back up a VM as this may cause issues with CBT.
Edit: To remove incorrect information. Please see follow-ups further down the thread. Long story short -- use of CBT in one backup product does not conflict with use of CBT in another. The change block request the backup application sends to VMware includes the snapshot ID of the snapshot that was used to generate the backup the application is using as a base. This ID give VMware a baseline to use for calculating the changed blocks, similar to the way NDMP uses dump dates to determine what files have changed.
One more thing that seemed relevant -- if CBT were to be disabled, you wouldn't have to worry about this scenario since the software will run a full each day. That may also be a viable option depending on the size of your VMs.
I spoke with another one of my colleagues and there may not be an issue with VADP and CBT due to the way VADP uses snapshots. I will update the thread once I have a more thorough explanation available.
I have been given more detail by another colleague and CBT works more like NDMP dump dates than like database transaction logs.
For each CBT backup, the backup application requests that vCenter take a snapshot. This snapshot is assigned a unique GUID which is returned to the backup application and saved. VMware maintains a record of the GUID and the date and time when the snapshot was created even after that snapshot has been removed.
The next time a CBT backup starts, the backup application will provide the GUID to use as the CBT base. VMware will calculate what blocks have changed since the snapshot with that GUID was created and return that list to the backup application.
There will be no conflict between multiple applications using VADP since each application is responsible for remembering what snapshot GUIDs were used for its own backups. This is similar to how dump dates work in NDMP.
My apologies for any confusion.
Awesome, so to clarify, if we are using CBT (TSM) and VADP (Avamar) we could potentially have an issue? But if we are using VADP and VADP we are in the clear? Or will their be a unique GUID's either way? I just want to confirm. Thanks,
CBT is a feature of the VADP interface. If you're using CBT, you are using VADP.
There will be a unique GUID either way so there will not be an issue.