VMFS Block Size and Incremental Behaviour

[Stoo]

We have several massive servers on 8Mb block vmfs3 datastores from our olden days of vSphere 4.1. Lots of these are SQL boxes with incredibly high volume of very tiny changes within their databases.

My understanding is that if one ~3Kb row within a humongous 800+Gb database changes, it'll earmark that entire 8Mb VMFS datastore block with the CBT filter as 'changed' to be backed up during the next incremental pass. Sub blocks from my understanding are only applicable to small files on datastores, and won't apply to minor changes within a huge vmdk i assume? As a result, i'm routinely getting 200Gb worth of changes on some of my SQL boxes daily.

Were i to theoretically blat and recreate some datastores as vmfs5 with the reduced 1mb block size, logic would suggest that a similar tiny change within this database on a vmdk would only change a 1Mb block rather than a 8Mb block and multiplied hundreds of thousands of times over, would bring down the number of Mb worth of changed blocks that need to be parsed each time a veeam pass runs and speed up my backups significantly and also reduce snapshot growth during the period of backup (as smaller blocks are changing each time a ~3Kb row is written). Is this correct or am i barking up the wrong tree here?

I'm not against doing this, but obviously only want to create work for myself if there's likely to be a tangiable benefit from doing so. Anyone have any comments/experience on this?

Cheers!

[Vitaliy S.]

Actually CBT block size is not related to VMFS block size at all, and is many times smaller than VMFS block size, so moving your VMs to VMFS with 1 MB block size will not reduce the incremental backup file. Thanks!

[Stoo]

Actually CBT block size is not related to VMFS block size at all, and is many times smaller than VMFS block size, so moving your VMs to VMFS with 1 MB block size will not reduce the incremental backup file. Thanks!

That's really good to know, thanks for the really speedy reply Vitaliy - you've saved me a lot of unnecessary work!

I realise this is moving outside of Veeam's jurisdiction and more of a VMware query, but would snapshot growth presumably operate the same way with an unrelated block size that gets used for delta writes, or do vmware snapshots grow in full-VMFS-blocksize increments? If i can shave a bit of snapshot growth off during my backup window and speed up the consolidation at the end by migrating, I still might press on with moving to vmfs5.

Cheers again.

[Vitaliy S.]

Let me try to address you question from a different angle...If the major pain is snapshot size during the backup window, then you definitely should leverage our new parallel VM processing feature which is available in v7. With this option enabled all your disks will be processed in parallel and snapshot shouldn't grow as large as it was when using Veeam B&R v6.5.

Moving to VMFS 5 is generally a good idea, but keep in mind that VMFS block size does not noticeably affect VM performance.