Scale Out Backup Repository

[messher]

Hi,

what do you think about creation of a scale-out backup repository adding 2 storage repository that are 2 different volume on the same server?
I would like to go through this kind of configuration because i need to utilize another volume on the server, because i cannot extend anymore the previous volume that i utilize as a simple storage repository.
thank you.

[PetrM]

Hi Bruno,

You are good to go with it but just in case don't forget to have a look at this check list.

Thanks!

[masonit]

Hi!

I am using this thread because my question is somewhat the same.

I plan to have multiple sobr (data locality), one for each customer / tenant. With all having extent that are targeting the same xfs volume. Each extent will just have its own folder on the volume. Could this be an issue for Veeams logic where backupfiles should be placed?
Also is there a limit for how many sobr you can create. Does not look like it with Enterprise Plus edition.

\Magnus

[PetrM]

Hi Magnus,

It should not be an issue for our logic. There is no "hard-coded" limit for the number of SOBR.

Thanks!

[masonit]

Sounds good. Of course I also plan to add multiple extens to each sobr if needed. For example sobr1 with extent1 on xfs vol 1 (folder sobr1_extent1) and extent2 on xfs vol 2 (folder sobr1_extent2). Then sobr 2 with extent1 on xfs vol 1 (folder sobr2_extent1) and extent2 on xfs vol 2 (folder sobr2_extent2). Would that be fine?

\Magnus

[PetrM]

Hi Magnus,

It should be fine, I don't see any issues with that config.

Thanks!

[masonit]

Ok, thanks!

Another question. If I have an XFS volume (vol1) with reflink active. Is it ok to have sobr1 / sobr1_extent01 (with fast clone active) and sobr2 / sobr2_extent01 (with fast clone deactived) both using vol1? My idea is to only use fast clone when necessary (gfs, immutable). Other jobs will run normal forever forward inc with merge. I know merge also can use fast clone. But I have bad experience using refs and daily fast clone merge with a lot of fragmentation. I only want to fast clone when needed.

\Magnus

[PetrM]

Hi Magnus,

Yes, you can do it as this is a "per repository" setting but did you try to schedule compact task to decrease fragmentation impact?

Thanks!

[masonit]

Hi!

I am using this thread with a follow up question about XFS. I plan to setup some new repositories with xfs. I am not sure at this point if I need to use the fast clone technology. But I want to have it as an available option. Plan is to create all xfs partitions with reflink activated. Could that be an issue / disadvantage if I end up not actually use the reflink function?

\Magnus

[jorgedlcruz]

Hello Magnus,
The only two things, you will be adding to these partitions are the reflink=1,crc=1 according to the next document https://helpcenter.veeam.com/docs/backu ... ml?ver=110 I truly do not think it will affect negatively whatsoever, as the block size is always 4096 no matter if the fast clone is enabled or not.

I would recommend the use of a fast clone for obvious reasons of disk space savings, and speed on the synthetic operations, but if you have enough space and you want to start without that enabled on the Veeam repo, that is fine as well.

Keep us posted

[masonit]

Hi!

Plan is to use sobr with repo with fast clone not enabled. Backups using that sobr will run normal forever forward inc backup. If there is a need for data to be immutable. Then I will create another sobr with repo using fast clone technology. Thoose backups using that sobr will use inc with synthetic full. All repos for all sobr will be using the same xfs partition with reflink=1..

\Magnus

[PetrM]

Hi Magnus,

You cannot use forever forward incremental mode for backups residing in a repository with immutability enabled: an immutable backup can be merged or deleted only once the immutability time period expires. However, you still can use "normal" forward incremental mode with periodic synthetic full on immutable repo, block cloning feature will significantly increase synthetic operation speed and ensure space savings. Basically, I'm not sure that I understand how fast clone and immutability features are related to each other in your case.

Thanks!

[masonit]

Yes I know.

My concern was if it could be a problem using xfs (reflink=1,crc=1) partition and never using the block cloning feature. Our standard backup is forever forward incremental mode. But I want to have the ability to use block cloning feature with immutable repo if needed in a future case. I can controll that on repo level. But I need to make the choose when I create the xfs partition. Because I guess reflink=1 can only be enabled when I create the partition..

Reason why I don't want to use the block cloning feature for all backup jobs is because I have a very bad experience with that feature in the past. Especially with slow performance because of fragmentation in refs. I only want to use that feature when needed. As with immutable..

\Magnus

[PetrM]

Hi Magnus,

Thanks for clarifications! I don't see any issues with the disabled fast clone but I recommend to use it whenever possible for space savings and increased performance of synthetic operations. I wouldn't take into account your past experience with REFS, but even if you have the same issue with XFS it will be better to find out the root cause than to give up fast clone.

Thanks!