If your Veeam backups and restores are taking a lot longer than you expected them to, take a look at your underlying storage architecture of your Veeam repository. There are multiple layers to how your repository performs. Let’s examine Veeam repository best practices in order to improve backup performance and reliability.
Before we get into specifics, a great primer is Brent’s post on configuring your file system block size.
One area that often impacts virtual backup performance is underlying RAID stripe size and RAID type. With backup storage increasing in size, a lot of people lean towards larger RAIDs as standard because they want to maximize their space. However, when it comes to performance, you can’t just focus on how much space is available, you have to consider how the storage is going to perform. It’s easy to hit a large storage number with a lot of large, inexpensive disks, but this won’t give us the performance that we need for virtual backups.
Understand this about your backup repository: it will be very split between read and write activities. So, stripe-based RAID5 or 6 will give more capacity but provide lesser performance than a RAID10.
For reference, use this stripe size calculator to get an estimate on your particular RAID performance.
Backup Performance and Storage Stripe Size
To better understand the storage performance, we need to start with the foundation. In other words, the storage stripe size.
Most storage arrays come with 64KB stripe sizes or allow customization. However, Veeam generally uses a set block value. As a default, the Storage Optimization option is set to Local Storage, which is actually at 1024KB. If you are using Veeam compression, it compresses the values in half. Each of the values below will be half the size when they arrive at the repository. So, the default block size for Local Target is going to be 512KB.
| Local target 16TB + backup files | 8MB |
| Local target | 1024KB |
| LAN | 512KB |
| WAN | 256KB |
The above table shows us how the different Veeam targets correspond to block size. We should expect, when using Veeam, that our backup files are mostly going to be large files. With these large file types, we can benefit from the large block sizes. Therefore, I would recommend using 64K NTFS clusters for all Veeam backup repositories. When using Windows repositories, the default FRS size can become an issue. Veeam recommends formatting Windows repositories with a format /L command, which will use the 4k FRS in the MFT.
Just because Veeam is writing at 512KB blocks doesn’t mean that 512KB blocks are what’s hitting the storage. In reality, that is just what hits the file system, which then breaks it into its block sizes and ships it to the RAID controller. From there it has to either write it or coalesce it and write many blocks at once or break it up into smaller blocks. Keep all of these things in mind when formatting your storage. Read up more on this in Brent’s post, Properly Configuring Your Filesystem Block Size.
Note: doing /L does not actually change your default unit size. We would also want to make sure in this command that we also use a /A to set unit size. For example, a command similar to this: format d: /L /Q /A:64K. (FYI: adding the /Q will utilize the Quick Format option.)
Note: even with the best block size and unit size selected, it’s very important to have a defrag task scheduled to be sure the repository is not getting fragmented.
The most important part of all of this is that these decisions and configurations must occur at the beginning. None of these features can be changed after the initial configuration, so put great thought into them before you start backing up.
While these are good considerations, remember that you need to analyze your specific working set to truly know how to lay out your underlying file structure for the best results.