Link Search Menu Expand Document

Block size consideration

Physical Layer Settings

The following information is from a forum post by Anton Gostev linked here:

https://forums.veeam.com/veeam-backup-replication-f2/thanks-for-the-veeam-and-refs-magic-t59927.html#p331597

Based on Veeam 512k block size ( see the next section on setting this in the Job settings), Veeam recommends a RAID stripe size of 256kb versus the default size of 64kb.

Example: With a backup block size of 512kb and a RAID stripe of 64kb, it would take 8 IOPS to read 1 Veeam backup block. If you set the RAID stripe to 256kb, the same read would take 2 IOPS. This would greatly reduce the requirements of the storage performance.

Veeam Job Settings

The block size of the backup file can impact the performance of the backup repository. Choosing the right setting should be based on the storage, not necessarily on the location of the storage.

Backup copy jobs inherit primary backup jobs block size setting

This setting is under the Storage tab in a job

Advanced Settings – Storage, Storage optimization:

Here are the Storage optimization settings currently available with their corresponding block sizes:

Storage optimization Block size Block size with compression1
Local target (large blocks) 4096KB 2048KB
Local target 1024KB 512KB
LAN target 512KB 256KB
WAN target 256KB 128KB

Which block size should you choose? See the next section: More Block Size Information

Veeam can use different block sizes to store backups on the target. The block size is defined in the backup job settings and will be kept across all copies.

Non-VM backups settings are set to Local target automatically, and the size cannot be modified.

Block size changes are only activated by an active full and will only be used for the new backup chains (the data stored already are not touched).

More Block Size Information

This section will focus on additional information to keep in mind when selecting the block size in your job configuration.

For most use cases, we recommend the default block size: Local target

Note: No matter what the actual target is, if offloading to Capacity Tier (object storage), then Local target (large blocks) or Local target should be used to take best advantage of the object storage and minimize API calls.

Space Savings Considerations: Block size matters! Whether you’re using a storage that supports block clone savings (i.e. ReFS/XFS/object storage) or a deduplication appliance, the smaller the block size, the more space savings are to be had.

That said, we typically do not see partners using a block size smaller than Local target. This also plans for success in case Capacity Tier is added on a later occasion.

Capacity Tier Considerations: Every block equals at least 1 API call so they can add up quickly and are a billable item for most object storage providers. For example, let’s assume you offload 1TB of data daily to object storage. Let’s compare how the estimated number of API calls vary by block size:

Block size Number of API calls
4096KB 250,000
1024KB 1 million
512KB 2 million
256KB 4 million

1TB/{block size} = Number of blocks = Number of API calls

Another thing to consider is egress charges during restores from Capacity Tier. When restoring backups, Veeam only downloads the blocks it must from the Capacity Tier and will prefer already existing local blocks. As mentioned in the space savings considerations, larger block sizes result in less duplicate blocks. As such, it could result in higher egress charges due to more downloaded blocks.

  1. We estimate usually a 50% reduction when compression is set to “Optimal” (the default value).