[VHRISO] VHR design

[johannesk]

Hi,

I am preparing to setup VHR in our environment, and we will be using the new VHR ISO on the repository server. I do not have any previous experience with VHR.

Things I am wondering about is.

#1
We have primary backups jobs with retention of 7 days. Then the copy jobs have retention of 60 days. Since immutability duration is configured on the repository volume, would it make sense to have separate repository for primary jobs and copy jobs?

2#
The repository server is using a direct attached SAN array for storage (Lenovo Thinksystem). We will be creating Dynamic Disk Pool. Is it any problem for the XFS and the immutability feature to extend the disk later?

3#
In this kind of setup where there is a repository server and direct FC attachment to the storage array and XFS, does it make sense to create repository chunks and bind them with SOBR? That is what we did with our ReFS repository before, and I think the main reason for that was so that we did not have bigger than 100TB repository extents. The total size of our XFS is 1PB, is there any reason to brake that into chunks and use SOBR?

Regards,
Jóhannes

[HannesK]

Hello,

#1: backup jobs and backup copy jobs point to two different physical locations to meet the 3-2-1 rule

#2: very likely the installation will fail because the Hardened Repository ISO currently does not work with multipathing devices (which is okay, because only internal disks are supported currently according to the system requirements)

#3: No, the better way is to have one repository (SOBR extent) per physical machine and use LVM (striping) to work around storage limitations (e.g. 128TB LUN size limits). One XFS with 1PB sounds good to me (there are some customers using that size)

Best regards
Hannes

[johannesk]

Hi Hannes,
Regarding #3 SOBR or not SOBR in this case. What are the penalties of creating 5x200 LUN's on the array, and bind them with SOBR on the repository when compared to just creating 1PB LUN and have one repository extent? In our case there is only one physical repository server in the datacenter with direct FC to a disk array. Then we have one physical proxy also in the DC and identical setup in the remote DC.

And regarding #2 yes we are unable to use the ISO VHR because of the FC DAS (multipath connected storage) is that a temporary limitation or is it likely to be permanent?


Regards,Jóhannes

[HannesK]

Hello,
#2: I hope that to be temporary, but it depends on how it goes with internal disks. It's mainly about avoiding that Veeam support needs to troubleshoot multipathing on hardware level.

#3: if you do it with only 5x200TB, then the biggest penalty probably is the wasted space you have and you probably will try to manage the balancing at some point in time. If you do that with 50x for example, you might see other side effects in the software, which are hard to predict upfront. The message is: one server should host one SOBR extent if SOBR is used. Yes, one can stretch that a bit, but SOBR is not designed being a "storage manager".

Best regards
Hannes