Backup job - amount of data "read" - what does it mean?

[Fiskepudding]

Is there some (other) way to test that? Just ro rule out that it is an Veeam issue?

[Gostev]

Call queryChangedDiskAreas function of VMware vSphere API with changeId parameter set to *

[Ian Cook]

[merged]

Hi,

Just installed Veeam 6.1 and patched with patch 1 on a customer site. All seems fine, the Veeam server is Windows 2008 R2 SP1 on a physical server, with a Dell MD1200 attached for backup storage. The ESX is 5 Update 1, hosts are on build 768111 all the VMFS is version 5, running on a NetApp 2240, not NFS.

When the backup is running, it sees the first 2 disks as 50GB, and is reading them as thin provisioned disks (all of the disks, including the 1TB ones are thin provisioned), ie 16.7GB and 425MB read in the progress. When it gets to the 3 x 1TB disks it is actually reading the full 1TB even though they are less than half full. Have not noticed this behaviour before, is this to be expected due to the 1TB size ? or is something else going on here ?

This is obviously painfully slow for the initial backup, at nearly 9 hours per disk, CBT is showing as enabled but obviously on the first run this doesnt really count.

Can anybody shed any light on why this may be, as im a teeny bit confused at the moment lol

Havent logged a call yet, as im not sure if this is by design or not, but perfectly happy to do so if it will help ?

Many thanks

Ian

[foggy]

Ian, please look through this thread for the possible reason. The other assumption is that some data could be written and then deleted from those disks creating a large number of "dirty" blocks (those unused by the OS but not zeroed due to how NTFS works), which are read during backup.

[Ian Cook]

Ah, that makes perfect sense foggy, thanks for linking me through, i have limited access to the forums on the site i am on, so searching is a bit "problematic"

Will have a proper read through

Thanks again.