Veeam Repo’s and IO patterns

[badabing888]

Hi all,

I’ve posted on here previously about IO testing Veeam repo’s so far the information provided in the forums has been great and we are busy drilling down deeper into some additional testing.

I was wondering if anyone had any stats on IO patterns for mixed jobs for the target repo and how this might shift the IO pattern to be more random for example

A repo who’s being targeted by synthetic fulls, forever forwards and reverse incrementals and how this might affect the IO pattern from sequential blocks written

Does running multiple repo’s cut from a larger backend storage device add to the fragmentation and random IO when running different types of jobs as multiple repo's seek on the backend disks to write / read its next block.

Does anyone have any good FIO tests outside the basic 3 types simulating file size / block size and read / write mix ?

Extra points if this is in XFS!

[HannesK]

Hello,
if the final question is "stripe size of the RAID controller", then 256KB is fine.

If it's about trying to improve performance with many small repositories, then you might create unwanted side-effects. For example splitting a 1PB storage into 20x50TB SOBR would end up with very little space efficiency.

Block cloning: fragmentation happens. It's how it works.

As you already have FIO tests that are probably similar to the diskspd tests we use in support... let's see what other customers have.

Synthetic fulls create many small IOs (don't know which block size) for the fastcloning operations.

Best regards,
Hannes

[badabing888]

Thanks for the reply.

Perhaps for clarification.
For example you have 1 PB of back end storage.

You slice this into 200TB repo's then use SOBR of 5 x 200TB extents.

If you ran say 30-50 Jobs across that SOBR of varying types active full, syth full (Block cloning), reverse incremental etc
Lets normalize the block size to 512K as this seems to the most common tested.

As you now have job 1 for example writing to repo 1 ,job 2 writing to repo 2 simultaneously you will have the back end array writing blocks at various points and while doing so it would be seeking on the disk heads where to place that next block.

As multiple jobs are running individual jobs will be some what contiguous blocks but the action on the backend as multiple jobs / repo's are running at the same time will to have those blocks in potentially random places? Over time can this cause additional fragmentation and thus causing IO to be more random (slower) and less contiguous?

Some info around this or some tests cases would be great to get an idea how much veeam repos are contiguous vs random IO to bench mark more accurately.