Linux Hardened Repository Shared

[Matt.Sharpe]

Hi Guys,

We have an upcoming deployment where we have 2 sites, connected with a MPLS which will both have a LHR onsite for the on premise workloads. The plan would be to have LHRs on the opposite site act as a target repo for offsite copies. Separate disk/folder of course.

I’ve read many forums and the site itself which says a LHR cannot be shared between 2 VBRs. People saying it’s impossible.

It’s not impossible, I’ve got this working actively in a lab, no issues with adding, rescanning, backing up etc. all tested on schedule and also simultaneously.

My question is whether there is a specific reason for this, or if the supportability is just the same as windows. You can’t share components between different VBRs etc.

I can imagine the upgrade being more involved for both sites, however this does work. So why is everyone saying it can’t work, or just exposed risk?

[HannesK]

Hello,
it sounds like you see the behavior that is described in the sticky FAQ..

Best regards,
Hannes

[Matt.Sharpe]

Hi Hannes,

I see it is your post too!

Q: Can a Hardened Repository be shared between different backup servers?
A: Technically that works, but it's an unsupported scenario.
1) Officially sharing servers / components between different VBR servers is unsupported. The reason for that is that the two VBR servers don't know about each other which means the server could be overloaded due to too many tasks. Plus it creates challenges during upgrade, as all components need to be updated together. So that scenario is not tested by Veeam QA.
2) As long as you keep an eye on the load and do not overload, it works fine
3) Also sharing a Hardened Repository between multiple VBR works fine with 11a. Each VBR server gets its own certificate (so that scenario was considered during development).

None of the above says it won't work, proved by the fact it is working in my lab. Other than losing automated control on the server load and having a dual upgrade requirement. Why is it plastered everywhere that this is cannot work, shouldn't be done etc. It clearly does work, but I'm trying to understand the risks before it's deployed.

Shared components have been "warned" for a long time. Never personally seen any issues.

[BackupSlacker]

Because they don't develop/QA for that specific case, so why are they going to promote doing it and then be required to support it when a user has an issue?

[Matt.Sharpe]

In other instances (for Windows) the terminology is always, not recommended. However with LHR, they're stating specifically not supported. Which points to a more specific issue, but yet to find it.

If it's not supported, it's not supported. No choice at present.

However the use case to have 2 VBRs using the adjacent repositories should be common. Especially for 2 sites that have a large number of important workloads. If the link goes down, customers are supposed to accept no backups in the opposite site because of the limitations put in play.

Also now got to bend on design elements that clearly work, but won't be supported because not tested by development. Frustrating.

[HannesK]

Hello,
if repository sharing is needed, then cloud connect is the recommended way. Cloud Connect is also available for end customers of a certain size / technical requirement. Your local Veeam representative can help with that. "Cloud Connect Enterprise" is the key word.

Not recommended vs. not supported: If I remember correctly, then we "always" had that for Windows and that's a different R&D team. Hence the difference.

Best regards,
Hannes

[p.demoura]

Hello people
We have deployed a couple of shared LHRs (UBUNTU Server 22.04), one of them with 4 sites running indipendent VBRs. It works like a charm Backing up some 5 TB nightly since VBR Version 11a was released. Nevertheless, we're completely aware, that if it fails, we'll be probably at our own...
However, as the linux stuff is straight forward and the way veeam handles the LHR is well documented we decided to take the risk.
However, there were (and still are) some pitfalls, but to our opinion, nothing magic.

1. and most obvious: every site needs it's own veeamuser login pointing to it's own directory(s).
2. when creating the repository it might be necessary to manually adapt the ownership and access rights to the users repository (directory)
3. Watch the simultaneus streams configuration (in function of the available cores) to the reposistory, so it won't run in any situations where it would overload the LHR resources.
4. and very important, all involved VBRs must run the same patchlevel.
5. when updating (as we did 11a=>12.0), all VBRs must be already updated before starting the first console session on a involved VBR (on first start, the console will try to upgrade the repository).

Wishes:
We would extremly like to see, that veeam would officialy support this obvious ideal setup of multiple VBRs pointing to one LHR as Linux is ideal and made for multi- user environments.

[matteu]

Hello,

I would like to have more information about the documentation and specially when we share a harden repository.

My customer has 2 VBR server and both use the same physical server as repository.
1 use /folder1 and the other /folder2.
Both are setup with hardened repository.

I would like to know if this is supported configuration or not ?

On documentation, I see Veeam hardened repository can't be share between 2 VBR. That mean the server itself or only /folder1 can't be connected to both server ?

https://helpcenter.veeam.com/docs/backu ... ml?ver=120
"The hardened repository cannot be shared between different Veeam Backup & Replication servers."

Thanks

[Mildur]

Hi Matteu

I moved your question to the existing topic we have.
While it works technically since v11a, we don't support this scenario.

Best,
Fabian

[matteu]

Thanks for your answer.

[Matt.Sharpe]

Is this raised/requested to be supported with RnD ? I feel like it works (got it lab'd and tested before). Surely it's something beneficial to add to supportability?

[Gostev]

Right now multiple backup servers are unaware of one another in terms of resource scheduling and it is a MASSIVE undertaking to implement. Besides, this logic will have other major consequences too (like much longer backup infrastructure resource selection and booking iterations) so realistically I don't see this supported in the foreseeable future.

[RichT]

The thing you could try is setting up an S3 Compatible Storage (with Ceph for example).
You can then have different Buckets with object immutability for the Servers and share the underlying storage.
It might not fit the performance requirements but it might be worth a shot.