VIB Size

[topry]

Using Veeam 5.01 installed on 2008R2 running within a VM
Target systems is also 2008R2 dedicated file server. With 3 drives, all provisioned as thin.
C is 75GB and is OS only, D and E are each 500GB. Total disk space used across all 3 is approx 300GB.

Backup using Direct SAN Access, Incremental backup mode, VSS option is checked.
Remainder of the options are default - change block tracking, inline dedupe, etc.

Everything seems to work well, performance is good, all traffic is going across the iSCSI connector at a good rate.

However, even if there is no activity (ie after hours, no file i/o), the minimum VIB size is 150+MB.
Currently, there is no anti-virus nor disk defrag software installed.

Average run with no activity is sub 3 minutes start to finish and if I run it sequentially / immediately, the min is always 150MB+.
AFAIK, there have been no changed blocks (other than perhaps what Windows changes when VSS does its snapshot).

Is this normal / to be expected or is there something else going on?

[tsightler]

Pretty normal. Windows is always changing something, writing logs, updating file access timestamps, swap cleaning, etc, etc. Veeam uses 1MB blocks, so it potentially takes as little as 150 bytes changed across your entire disk to make a 150MB VBI (this assumes that each changed byte is within a different block). More likely you actually do have a few MB's of changes, but that's being reflected as 150MB of changes in Veeam because of the large block size.

The two biggest things you can do is to disable file access timestamps, and move swap to a different disk that is excluded from Veeam. You could also potentially use the LAN Target or WAN Target backup modes, which cause Veeam to use 512K and 256K blocks respectively, but they do have some performance considerations.

Interestingly, this phenomena is worse for virtually idle systems because the overall change rate is very low and and the small block updates for last access timestamps have a tendency to be spread across blocks. For a busier system this small noise is typically a small percentage of the actual change rate, and the changes have a tendency to be clustered together making the larger block size less of an issue. The exception to this are servers like Exchange and SQL which generally have lots of small changes all over the disks.

[topry]

Thanks for the reply/info. I had not considered the 1MB block size - that explains a lot.