Differential not supported for this VM

[derwin]

My nightly differential backups are always falling back to full backups on my VMs. The message is "A Full backup was run on this VM, since the option to fall back to a full backup was selected. Incremental\\Differential backup methods are not supported for this VM.". None of my VMs will do a differential backup.

I am running vSphere 4.0 and Backup Exec 2010, the Agent for VMWare Virtual Infrastructure license is installed. All of the VMs have the remote agent installed. I believe ctkEnabled is set to TRUE on all of the VMs and their drives. It is on any of the VMs that I have been able to take down and look at. I haven't had to set that by hand so I'm assuming they are all set correctly.

The jobs are created through a policy.

The differential job backup method for files is set to "Differential - Using archive bit (does not reset archive bit)"

The VMWare backup method is set to "Differential (vSphere only)"

Use Backup Exec GRT is checked and all of the GRT settings are enabled. I have licenses for all of them.

Where else can I look to find out why differential isn't working? The backup works fine, I just want to be able to do differentials or know why I can't.

Thanks,

Dave Erwin

[RahulG]

have you applied the following hotfix http://support.veritas.com/docs/337860 .. I belive installing this should resolve the issue

[Colin_Weaver]

If you know what you are doing you can use the ESX Managed Object Browser (MOB) to confirm that the Capability "changeTrackingSupported" is set to true against your virtual machines - however as you state ctkEnabled has been set against some machines in your enviornment - my guess is that it is set correctly.

Warning though don't use the MOB if you don't know what you are doing as any accidental change could break a VM or potentially your ESX server.

[enablenj]

I am getting this issue every night with Backup Exec 2010.  I did not used to, and I'm not sure what changed.  I moved some VMs from one datastore to another, but I have run regular full backups since then, rebuilt the entire job and selection list.  I am going to try to select the virtual servers through their individual ESXi hosts, instead of through the vSphere server, and see if that is what changed (these backups ran properly before I rolled out the vSphere Server).  I will keep you posted, but it'll be a couple of days, because I'll have to run a full backup tonight since I just completely changed my selection list.

If there are any other suggestions for why this might happen, please feel free.  Everything online suggests hotfixes and checking the change tracking, but BE2010 appears to have set the change tracking properly on all of my VMs, it has all of the updates suggested or available through LiveUpdate, and-- most importantly --this used to work.  The only change I can think of that might be impacting this is the roll-out of vSphere Server.  Hopefully selecting throught he hosts instead of through the vServer will clear it up. 

[Dextertronic]

Are you using Dedupe?

[enablenj]

I was using DeDupe initially, but I hit a lot of errors trying to move the backup sets over to tape at the end of a week.  I had to give up because I had to get back to running proper backups, and I'm able to put one Full and 6 Diff backups onto a single tape each week and run the backup overnight easily within the backup window.  So using dedupe wasn't a priority.

I scratched that, and went back to straight tape backups, 1 Full and 6 Diff, and things worked fine.  Obviously I had entered my vSphere Essentials key on these formerly ESXi 4.0 machines, and was backing up the VMs directly.  It worked fine.  A week or so later, I rolled out the vSphere Server, and altered the backups so that on the selection list, the VMs were selected within the vSphere Server, instead of selecting them within the actual host containers.  After that, none of my Diff backups worked, and it kept taking Fulls every night.

I threw out that selection list Friday after I posted above, and started from scratch, selecting the VMs within their respective host containers.  Voila!  I'm running nightly Diffs again.  I did get a snapshot error from one of them, but that's probably not related and I expect it'll be cleared up with a restart.

Apparently there is something about selecting the VMs within the vSphere Server container that caused this issue.