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?
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.
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?
I am having somewhat similar issue in our environment, its in the development phase, Avamar 7.0 VM image backup, I had just started to move backups into Avamar, at this moment they are backing up these VM through TSM, and today after the last night backups, few VMs were corrupted and had some drives missing.
Both the backup technologies do not run together at the same time, I have not faced this issue before.
Please help me to understand the issue. The log of the troubled VM that did finish the backup with exception, does mentions of having issues while quiescing for snapshot and then completes with exception.
Thanks in advance.
I'm not aware of any way Avamar itself could cause VM corruption or missing drives.
Based on what you've described seeing in the logs, it sounds like there may have been a Windows VSS failure during the backup of the virtual machine and that's what caused the backup to complete with exceptions. This also cannot cause corruption in a production VM (VSS is a Microsoft technology that is used to quiesce I/O to the disks before the backup so open files are in a consistent state when they are backed up).
I would recommend opening a service request for this issue.
Ok, If its the VSS quiesce cause, would using [avvcbimage]quiesce_fs=false work, one important thing I forgot to mention is all troubled VM are Windows 2008 R2, and this does have known issues with quiesce snapshot, correct?
VSS snapshot failures will cause backups to complete with exceptions, yes. And yes, setting the quiesce_fs flag to false will request a non-quesced snapshot from VMware which does not invoke VSS and will prevent the backup from completing with exceptions just because the VSS snapshot failed. I have two concerns with this, however.
Firstly and more importantly, you mentioned VM corruption in your previous post. I think you need to take a look at your environment to figure out what might be causing this -- VM corruption doesn't happen in a vacuum and it sounds like some component in your environment is not in good shape.
Secondly, disabling quiesced snapshots is only a workaround. Ideally, you'll want to determine why VSS is failing on the affected guest(s) and correct the problem so all the files in your backup are consistent.
Very well said, Ian, I will go that route, and by just join on the basics, no backup application touches the VM for image backup and so I do not believe it will cause the corruption, and I also think that the person that gave me the news of corruption is confused himself. I believe it is missing drive mainly, I will clarify this tomorrow and will take your suggestion on it, will let you know how it goes.