POSSIBLE SOLUTION / CAUSE....
(Sry, long post but hopefully the pro's can shed some light
I think i found the answer to the above question (Does veeam just backup everything CBT says has changed?)....Short answer....YES.
Through some testing today, i have found something undesirable (or maybe realised it rather) - which is probably the cause of my larger than expected increments.
One of these servers suffering from large increments has one 40gig drive. 22gig of that is used - when veeam does a full backup of this server the VBK file is about 7gig - a veeam increment for this server with CBT is normally around 500MB.
Today i copied an 8gig file to this server, deleted it, copied it over again and deleted it again - after this the 8gig file was now gone from this server and its used space was again 22gig. I than ran another increment of this server. Some of you might at this point see where this is going....
With no new data added to this server, the increment should be extremely small....but in this case, because CBT is enabled on this server, this next increment was 9GIG (which is even bigger than this servers base image!)......obviously this is because when i copied the 8gig file to this server, all those blocks changed, then i deleted it, then i added the 8gig file again more blocks changed.....at the end of this process, 9gigs worth of blocks had changed so when the next increment was run CBT told veeam that alllllllll these blocks had changed. Simple. But - no data was on these blocks....they had just been changed.
This was what i was trying to find out and it seems this is the case - CBT tells veeam that a block has changed, veeam just listens and then backs up that block, veeam doesnt do any further analysis (suppose there is an obvious answer here as backing up block level veeam cant actually see what is in the block so doesnt know if it holds data or not, it just knows that its changed). I suspect this is why the increments are so large, when a file is added then deleted or just deleted, blocks are changed and then because they are changed they are backed up - even if those blocks actually contain no data any more - like in this test, 9 gigs worth of empty blocks were backed up even though there was no data in any of the blocks - basically creating a huge increment with absolutely no real data in it.
Is it possible......when CBT hands veeam a list of all the blocks that have changed, is there any way that veeam could then process each block and test/analyse if it actually contains 'real data' - so that the backup is fast because only changed blocks are being processed BUT blocks which contain no data are NOT backed up? (or is my comment above about not being able to analyse the block level the limiting factor?).
I also suspect that this is why the veeam increments are smaller in size when you turn OFF CBT - because veeam is then processing the vm like other imaging products (although through the HV), not just listening to CBT about what blocks have changed. So without CBT your increments only contain new data so are small, but with CBT your increments not only contain new data but also possibly empty blocks which will blow out the size of your increments.
From testing - without using CBT the increments take just as long as the full backup, obviously because veeam has to process the VM each increment. Does anyone know why, without CBT veeam takes so long to process the VM and create a new increment? With agent based imaging apps, the entire server is processed with each increment - why can it do it in minutes but veeam takes the same amount of time as its full backup? I would like to turn off CBT to reduce the increment sizes BUT i cant because without CBT the increments just take too long. Both agent based imaging and veeam (without CBT) process the entire server for an increment but the agent based is so much faster - why does veeam take so long when its doing the same thing?
Thanks in advance for taking the time to read/respond