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.

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.

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.

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 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.

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.

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,

Rich

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.

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.

I am sorry I misspoke - I meant if we are using VCB (not cbt) on TSM and CBT/VADP on Avamar would they be assigned two different GUIDs?

Therefore the GUID through VADP would not be affected by the VCB backups, correct?  The GUID would go back to the last record and backup all changed data since then, yes?

My pleasure!

Thank you for the help and clarification.

VCB and VADP work slightly differently. They both take snapshots (which will be assigned distinct GUIDs) but I don't believe the GUID is used in VCB since VCB copies the VM data to a proxy and the backup software backs it up from there.