Microsoft 365 backup repository blocksize recommendation

Hi Michael,

thank you for your answer!

Then I would assume using NTFS with 64KB cluster size would be the best option. At least, when object storage isn’t an option at the moment. ReFS does not give us any advantage compared to NTFS in this scenario, correct?

What is your experience with Move-VBOEntityData? We did some migrations with that in the past, but there were always some users, sites, etc. that couldn’t be migrated. That’s why I’m not sure if we should use that here, because I don’t want to end with job’s data spread over multiple repos… ;-)

Best regards

Christoph

Thanks for the update! Don’t forget to mark this question as answered to help others in the future! 🙂

Hi @HannesK it comes from https://bp.veeam.com/vbo/guide/buildconfig/proxy-repo.html

Unless this source is out of date?

Agreed, I reviewed the thread you linked in your previous post (didn’t spot the link initially). I clearly mis-remembered the reason why we disable integrity streams, probably in part due to integrity streams being focused on corruption prevention! Thank you for highlighting this to me so I can better advise moving forwards.

I’ll edit the previous post and to clarify for everyone here, it’s not corruption reasons but performance reasons as per @HannesK’s linked thread that you would seek to disable ReFS Integrity Streams when working with VBM365.

To post @Mike Resseler’s comment from the thread:

Disabling integrity streams is recommended, but the reason for the recommendation is performance. 

If integrity streams are enabled, all write operations become allocate-on-write operations. This avoids any read-modify-write bottlenecks since ReFS doesn’t need to read or modify any existing data but file data frequently becomes fragmented, which delays reading.

Depending on the workload and underlying storage of the system, the computational cost of computing and validating the checksum can cause IO latency to increase which will be the case with a running database. So I would advise to turn it off.

Hey, Veeam Community. I just found this thread and I wanted to ask if there’s any reason why it’s either 4K or 64K cluster size. Smaller cluster sizes help to minimize wasted space when storing smaller files. 8K cluster size would allow 32TB limit and 16K would allow 64TB. There would be use cases out there for tweaking the cluster size to balance maximum volume size with storage efficiency. What do you all think?

Well if you think on “average” the size of files in Veeam Repos, the amount of space used is going to be so minimal, and the performance gains are going to be so large that it’s a no brainer to go 64K REFS.

Hin is correct, I was responding to HangTens more generic question about block size and saving space. 

It goes back to “This is the best practice, except when” , or “Always do this, unless”

Sure if you have a ton of super small files and have a ton of I/O smaller block sizes make sense.

I’d also add though a 16TB cap on your volumes is going to get old quick when we are dealing with backups. As things grow I can’t tell you how annoyed I get when a coworker sets a blocksize to 4k on a file server lol.  

EVERY TIME 

• Customer says running out of space, or volume offline as it’s out of space.
• Expand drive in VMware because customer wants space. 
• Expand drive in windows. UGGGHHH!!!!!
• Robocopy 16TB and DFS to new location on properly sized blocks.

I check now obviously after this got me a few times. haha. 

Again to echo an earlier point. NTFS is only recommended since you don’t need to disable integrity streams. It’s because they don’t exist on NTFS vs disabling them on ReFS, and if you forget, it’s only a performance penalty potentially you’ll encounter.

With that in mind I see no harm in going ReFS, and I’d do ReFS 64k to maximise partition size.

A single JetDB file can grow to 64TB, and Veeam recommend volumes no larger than 200-300TB in size, so you’d be maxing out way too prematurely by going 4k.

I’ve yet to find any documentation from Microsoft that discourages ReFS or suggests using smaller block sizes. If you’re gonna work at the scales that warrant it, it’s better to just ensure you’ve got sufficient IO performance to handle any IO amplification?

I know this is an old-ish thread… and this video is also a little bit on the old side, but as it pertains to the original question… at least according to this video on VBO365 best practices… at about 58 minutes into the video… go with 4k NTFS…

Based on their reasoning, and as has been noted several times in this thread, it's all centered around performance. And, while that video doesn’t discuss the 16TB size limit associated with 4k… they do mention several times to break up your data into multiple jobs based on data types (SharePoint, Exchange, etc.) and if needed even further by company characteristics (regional offices, company departments, etc.). There are also max recommended number of objects and other job characteristics listed in that video which help answer “how big is too big for one job.” That said, it’s reasonable to say that if you are slicing up your environment wisely and using an individual repo per backup job you might be hard pressed to hit the 16TB limit.

There are mentions of corruption issues… but that’s due to manually purging files or using object storage tiering schemes that VBO365 doesn’t work with. It’s never said to avoid ReFS or anything else based on corruption… just performance issues. Also, throughout the video they make mention of a few limitations that VBO365 had at the time which are now (mostly) resolved… but I suspect the NTFS 4k recommendation would still stand as of version 6 since it centers around performance and not about functionality. Happy to be proven wrong though. 😄 And… it is just a recommendation. One size doesn’t fit all… so do as you please so long as you do so understanding what you are potentially sacrificing by deviating from best practice.

Really fantastic vid!