Feature Request - Remove Capacity and Archive Tier Object Storage Restrictions

[c.haydock]

This has been moved from: https://community.veeam.com/discussion- ... tions-3274

I would very much like to have ANY storage target be allowed to be targeted/used for a SOBR capacity or archive tier. As a for instance… the primary performance tier for the SOBR lands on a RAID 10 of either HDD or SSD and then rather than being forced to use object storage for the Capacity and Archive tiers it would be possible to simply offload to another repo that sits on a much slower but more capacity efficient RAID 60 array of disks. That would be much appreciated.

That’s just one example of course, but the point is that I would like to have the system admin ultimately determine what they want to qualify as “performance”, “capacity”, and “archive” worthy storage. If they determine that based on their needs that the “performance” tier is a RAID 10 of SSD and their “capacity” tier is a RAID 10 of HDDs, and their “archive” is a RAID 60 of HDDs… let them be the judge of that. Don’t force their hand into using object storage.

For all anyone knows, what the backup/storage admin want as “archive” storage might be their old NAS refurbished/reconfigured because long term storage is a “nice to have” and they just want to take advantage of equipment they would have otherwise thrown out. Whatever the case may be… it would be nice to select ANY storage type for any of the tiers. Leave the admin up to deciding what is appropriate for their particular use case.

[c.haydock]

Replying to a comment from whence this was moved only because some of the same talking points may be brought up here...
​ 

Mildur wrote:
Feature request must be created in the R&D forums. This is the wrong place for them:

https://forums.veeam.com

Moved as requested. Thanks for the clarification.

V12 will allow you to use object storage as the performance tier. But the capacity and archive tier still only support object storage and I don‘t see that changing in a future version.

I know it’s far too close to the release of V12 to have this be a reality in the next rollout. But, that also gives them plenty of time for V13.

A backup copy Job to the „RAID 10 of HDDs“ or the  „RAID 60 of HDDs“ (can be configured as a second SOBR) which is refs/xfs formated has a similar behavior as the capacity/archive tier. I don‘t see what using them as capacity/archive tier will do much differently.

 
This first part is perhaps a bit trivial, but setting up a copy job is an increase in complexity that if it were simply implemented within the SOBR as the capacity or archive tier would eliminate some of the extra job setup to achieve the same results. Especially if you have multiple jobs landing on the SOBR… it’s just fewer extra copy jobs to manage if the SOBR is handling that part for you. The other half is that if the SOBR is at an off-site target (say for instance using a Veeam Cloud Connect repo), then there is no ability (to my knowledge) to conduct a copy job between the two at the far end. To my understanding, one would have to stand up two independent off-site repos and then have two off-site copy jobs, one to each repo… which is an inefficient use of bandwidth. However, having the far end SOBR be able to auto-magically move between a hot landing zone of RAID 10 and cold storage of RAID 60 would eliminate that limitation. 

I guess in fairness... I should also be asking to anyone in the know... "Why is the capacity and archive tier restricted to being only object storage in the first place?" Is there something magical that it offers that restricts other storage types from being used to obtain the same functionality in the SOBR? If the answer is simply "it's more efficient at doing XYZ"... well... then my request stands... let the storage admin determine what is best for their environment. If it's a case of "object storage is the only thing capable of XYZ.. and that's a key component to making the SOBR tier system work the way it does"... well... I would first and foremost like to understand a lot more about how/why that's a limitation and... and then I'll still ask if there's anything that can be done to work around that limitation.