Veeam Repository Best Practices – Part 2

In Part 1 of the series I covered off some of the basic hardware recommendations along with best practices for interacting with your storage. In Part 2 we are going to look at using Windows as a repository, along with RAID best practices.

Using Windows as a repository

If you are using Windows as the OS for the repository, there are some specific considerations to pay attention to.

Deduplication: Server 2012 R2 has a maximum supported dedupe file size of 1TB. Depending on your backup size, you might be over that. Per-VM job chains might be able to help you get around this if you are running Veeam version 9.The dedupe process is also single-threaded, so it might take some time to see those storage gains.

There are supposed to be improvements on this front with Server 2016. There is a thread over at the Veeam forums that indicates Microsoft doesn’t intend to test deduplication on files larger than 1 TB. However, based on tests that Veeam ran, it looks like larger files are still processed, but anything over 4 TB is skipped.

NTFS: Be sure to format the volume for large files (format x: /L) in order to support larger files. The maximum file size for Server 2012 is 256 TB. As of this writing, I can’t seem to find a maximum file size for NTFS if Server 2016. ReFS does support files up to 16 Exabytes though.

Also, be sure to check that your disk’s allocation unit size is set to 64K. Once again, the ever so useful Veeam forums have more information. Note that this is different than the RAID stripe size (we’ll get to that shortly).

Know your RAID levels

Everyone likes to have their disks protected, but at what cost? Depending on the RAID level you will see a hit on your overall storage and/or performance. There is an excellent table that was used in the VeeamOn session on repository best practices, which I have re-created here.

In order of preference based on protection and performance, you’ll want to look at RAID 10, RAID 5, and then RAID 6. If you like living on the edge, I suppose you could run RAID 0 – speeds would probably be awesome, but you may not have a job for long.

RAID 5 isn’t recommended too often anymore due to larger drives taking longer to rebuild. Back when drives were 250 GB, a failed disk in a RAID 5 array might rebuild in a couple of hours. Now with multi-terabyte drives, rebuild times can stretch into several hours or even past the 24-hour mark. Now consider that while the array is rebuilding, it is very vulnerable. If another disk fails, you’ll lose everything. This is when you start questioning why the disk failed. Was it an environmental issue? Maybe just a bad batch? Are there any other drives from that batch in your system now?

Long story short, figure out what tradeoff you are willing to make (protection vs. capacity vs. performance) and choose wisely. Yes, you can always change the RAID level at a later date, but you’ll need to blow away the data first.

While on the topic of RAID, let’s get back to stripe size. Most Veeam I/O is around 256KB to 512KB. In order to minimize overhead, a stripe size of at least 128 KB is recommended. Let’s say you have a 512KB block to write, and the strip size is 128 KB, that is 4 IOPS (512 / 128 = 4 ). If on the other hand you had a default stripe size of 32 KB (not uncommon for some arrays), you’ll be looking at 16 IOPS (512 / 32 = 16). Potential for a lot of overhead. If on the other hand you go and make the stripe size 512 KB, you might start running into a lot of wasted space. 128 KB seems to be the happy medium for performance / storage efficiency.

Once again, over at the Veeam forums, there is an excellent post that goes into a bit more detail. Although 128 KB will work in the common scenarios, there are more detailed recommendations based on compression, deduplication, and destination settings. You can find that thread here.

Along the same lines, you want to throw as many disks as you can into your repository. Going back to that chart up above, the more spinning disks, the more IOPS. Combine that with something like RAID 10 and you’ll get lots of IOPS, with minimal overhead, and good protection (at the cost of total available storage).

What’s Next?

Well, that is it for Part 2. Next up we’ll have Part 3 which will likely be the final installment of this series. In it, I’ll cover some recommended settings within the backup jobs, as well as general considerations when it comes to protecting your repository.

As I mentioned in my first post, a lot of this information has come from the free VeeamOn videos and the Veeam Forums. Be sure to check out those resources as they both have fantastic content.

UPDATE: Part 3 can be found here.