Spanned Volume - SOBR

[adam.costello]

Good morning all.
Customer has a windows VM, in a vsphere environment, that is over 135tb in size. This resides in a set of multiple iscsi luns, from a Nimble storage array. The size limit of 127tb on the nimble forces this breakout across different luns.
Currently, they are trying to snapshot the whole VM, and dump it to a multi-extent SOBR configured in Data-Locality mode. That mode was chosen for organizational reasons.
Unfortunately, the customer is using post-process deduplication on the Nimble array, and thus, the whole backup cannot fit onto a single extent in the SOBR. Thus the job is failing.
The customer asked about using a spanned volume and adding that to the SOBR in performance mode vs data locality. I understand the differences between the 2 configurations.
What is the best course of action here? The customer will be moving to a PBBA soon, but we are trying to get at least a good set of backups prior to that happening. They are currently using (R) and backing up the disks with the NAS backup functionality, and essentially breaking the job up. I advised that we should do that, and just snap the core vm.
Thoughts?

[rennerstefan]

Hi Adam,
can you provide a little background on what the customer uses as SOBR extends (system type, size, protocol...etc.)?
Would be good to understand what he has available to provide some ideas here.
Thanks

[PetrM]

Hi Adam,

As far as I understand, the main problem is that you do not have enough free space on a single extent to store a backup on it. Therefore, the idea to add an extent with sufficient space on it seems to be a good way to circumvent the current problem. I don't have any arguments against the usage of spanned volume.

Data Locality and Performance policies help to describe how to distribute files across extents and you choose the one according to your needs. Also, I'm not sure that I understand why do you want to switch over to Performance policy? The policy can be violated if there is no extent with enough space, for example on this page we can see:

The backup file placement policy is not strict. If the necessary extent is not accessible, Veeam Backup & Replication will disregard the policy limitations and attempt to place the backup file to the extent that has enough free space for the backup file.

Speaking about the choice between the backup of the whole VM and NAS backup, I believe it's worth defining what kind of recovery options do you want to get and decide on the backup method based on this.

Thanks!

[adam.costello]

"As far as I understand, the main problem is that you do not have enough free space on a single extent to store a backup on it. Therefore, the idea to add an extent with sufficient space on it seems to be a good way to circumvent the current problem. I don't have any arguments against the usage of spanned volume."
I cannot find documentation that states its supported. What about MBR corruption? What happens if it gets corrupted?
The reasoning behind moving to performance is due to the full backup being on a single extent and placing the incrementals on another extent. This is on the customer side decision, not mine. My original design was data locality mode, so that no matter what, the data would all be together.
Thanks again!

[adam.costello]

@stefan
Multiple ISCSI LUNs presentation to repository server as the SOBR due to 127TB Limitation on the nimble arrays.
This is the ONLY storage they can use, and its not a unified array, so ONLY block available.

[rennerstefan]

ok got you.
As Petr mentioned technically it will work that you create a "spanned volume" and use that within SOBR. Veeam only uses what it has access to from the OS level.
We don't span ourselves or really check what is behind the volume as we trust and rely on the OS here.
With that there is also no support statement because at the end it is up to the OS vendor to support the span.
That said it will work but you also mentioned the downsides that can happen if e.g. you run into a corruption on one of the span extends.
As this vm is so large you will need to find a way to store it and that is either buy a larger repo with more TiB or span the disks.

I'm with you, I would still try to use the data locality mode to keep everything together and if you span that should not even be an issue.

[adam.costello]

One of the problems we have found is that repository servers are being used, the Nimble has deduplication turned on. So, in the repository server it is not seeing the actually used space on the ISCSI lun. Does turning on windows deduplication identify this storage reclamation and update Veeam?

[rennerstefan]

no that will not help in my eyes.
the storage deduplication is hidden from the OS unfortunately as the OS only sees the iSCSI block device.
You would need to ask HPE if there is a way to get this done I'm not aware of any with nimble.

[adam.costello]

Thats what I was thinking as well, but figured I would ask in case.

Thanks all.

[rennerstefan]

as i just had a HPE storage specialist on the phone i asked for it.
Windows only sees the logical data (as I already guessed).
He is also not aware of any way to display the real data incl. nimble dedup/compression.

I recommend still to open a case at HPE to get confirmation.

[adam.costello]

Talked to an HPE specialist, and there is a powershell script/command that can do it, but that is too clunky for my customer, so not sure im going to use it. Ultimately, the idea is to move to a PBBA and get off using a storage array as a target for long term backups, and integrating with Veeam. Unfortunately, we are finding the limitations are just too much.