SOBR Placement Policy

[perjonsson1960]

Folks,

We have two SOBR in our environment, and both have the Placement Policy set to Data Locality, which means that a certain backup's files are all stored on the same repository extent. If I change the policy to Performance, does that mean that from then on, B&R will start to store the incremental backup files on a different extent?

I know that, in our case, the full backup files will remain on the current extent since we are using deduplication.

PJ

[PetrM]

Hello,

The extent selection logic will work according to Performance policy once you change SOBR settings. The idea is to store full and incremental backups files that belong to the same backup chain on different extents. You may find more information regarding extent selection logic on this page.

Thanks!

[perjonsson1960]

Thank you!

[perjonsson1960]

I changed the SOBR Placement Policy to "Performance" just over a week ago, in order to have the full backup files and the incremental backup files on separate extents. But now I get the feeling that merge operations and creation of synthetic fulls are painfully slow all of a sudden, at least when it comes to very large backup files. We have a file server cluster, for example, where the full backup files are approx. 17 TB, and the incrementals around 400 GB daily. And I have a retention period of six weeks, and a synthetic full is made once a week. And the merge operation usually takes less than an hour, but now it has been at it for over six hours, and it has done 50%... And there is another file server with about 6 TB of data, that has been doing a synthetic full for 13 hours and has done 93% when I write this. It usually takes about ten minutes...

Does it have something to do with the ReFS file system and deduplication? We are using B&R:s builtin dedupe, we have not activated the dedupe in ReFS. Should I change the policy back to "Data locality"?

[perjonsson1960]

When I came to work this morning, there are 18 jobs running, and it is painfully slow... I was under the impression that if I change the policy to "Performance", then all full backups would remain on the same extent as before, and ONLY the incremental backups would be put on another extent. But now the job with the 17 TB cluster is clearly creating a new synthetic full on the same extent that it has put the incremental backups, and that certainly wasn't my intention. This is awful! It will take forever! I have ruined our backup system by changing the policy!
What will happen if, when all these jobs have finished one day, I change back to "Data locality"? Will all the new synthetic fulls continue to be created on the "new" extent, where the first one is being created as we speak?

[jorgedlcruz]

Hello Per,
In my experience, Data Locality has always played better for me in my lab, and on the Customers, I have the pleasure to support. You also have a bit more control on where to enable dedupe at the storage level, where not, etc.

At this point in time, and seeing that it seems to point all over the place, I would recommend opening a support ticket, and keep working with our Engineers to help you achieve a stable and organized repository. There are options to move points between extents, etc. I have seen similar behavior with one customer before when I was an SE, and we ended moving points from one extent to another using the evacuation mode, rescanning repos, etc. But all it was supervised and checked with Support.

Share with us the case number so we can be aware. Thanks!

[PetrM]

Hello,

I believe that network design would be one more thing to consider. Basically, it's recommended to use 10 Gb networks for efficient communication between Data Movers on different extents.

Thanks!

[perjonsson1960]

Yes, we are using 10 Gb.

Case #05581026

[jorgedlcruz]

Thank you so much for the case number, let's wait a bit to see what are the recommendations from our Support Engineers.