Question on new V11 Linux repositories

[HannesK]

Hello,
yes - as long as they are the same versions (that's what you already have in place as far as I understood). If you need real independency, then chroot / containers can solve that.

With Hardened Repository (single-use credentials), hardware sharing is only possible with chroot / containers.

I cannot follow what your thinking is. Did you already read the whitepaper about Hardened Repository?

Best regards,
Hannes

[mweissen13]

Hello Hannes!
Thanks for the whitepaper, which further clarifies things for me.

I like the container idea, probably we will go with that route in the future. I will do a proof of concept of that configuration in a lab situation. Do you, by chance, know if INSIDE the container Veeam would still be able to detect and leverage XFS block cloning?

[HannesK]

yes, at least LXC

[mweissen13]

Hello Hannes!
I was successful on setting up a LXC container and deploying the Veeam Transport component there as PoC. Great!

However, I needed to fake xfs_info output in order for Veeam to correctly detect and use block cloning. Otherwise it would always say that XFS block cloning is not available. And backups would fail with "Invalid block size 0". Which is understandable, because xfs_info does not work from inside the container since it cannot access the underlying file system directly. I just used the xfs_info output from the host and made a xfs_info script inside the container that statically prints the same output. Is this expected or is there a better "workaround".

I could not find any howto on this topic so I am thinking about writing one.

[HannesK]

I asked my colleague who did that. He also used that "hack" in the beginning. But then he switched to presenting the volume directly into the container and formatted it inside the container.

[bc-109]

Hi all,

I posted a similar question in another thread :
veeam-cloud-providers-forum-f34/several ... ml#p428271

Gostev wrote:

My latest comment was specifically in regards to "Veeam needs to fix this or that bug with this scenario". This is not a scenario we test and officially support, so do expect possible bugs and don't expect fixes for them. We simply can't log any bugs for what is not officially a feature. Before we can do this, devs will require us to prioritize and then have them deliver the actual feature first: support for sharing backup infrastructure components between multiple backup servers.

It's important for us to know exactly what are configurations that work in some test cases, and what are officially supported ones. Questions :
1/ Is "Sharing a single XFS repository between a VBR server and a CloudConnect server directly (without LXC)" an officially supported feature ?
2/ Is "Using two separate XFS repos for a VBR server and a CloudConnect server on the same Linux hardware using LXC containers" an officially supported feature ?

Kind regards,

[HannesK]

Hello,

1: as Anton wrote... we don't test that scenario, but it works as long as there is no "overload". It's up to you to decide whether that's good enough for you or not. It definitely must be different paths in the file system, if different VBR servers are used. If two repositories of two VBR servers write to the same path, then it breaks.
2: containers or any kind of virtualization is transparent for the software. We don't declare support for every single virtualization technology in general. Running the repository role in a virtualized environment is supported, yes.

Best regards,
Hannes

[bc-109]

Hi Hannes, and as always, thank you for your fast answer

1: Yes, of course, the two VBR instances will write to two separate LVM volumes. Anyway, what would happen if we need to open a support case, as we are in an "unofficially supported" configuration ? Those would be production servers, and even mission-critical ones. We can't afford having no support on them...

1+ : For a small SP, using two instances of VBR (one internal, and one for CloudConnect) is a common scenario. This scenario is required by CloudConnect limitations (the server can not be shared with a normal VBR server). Then, as a Feature Request, would it be possible to add official support and tests for two VBR instances writing to the same XFS server ?

2: OK, LXC is just a virtualization layer. Unfortunalely for us, we don't use and support Linux containers (yet). May be added on our ToDo list

Kind regards

[HannesK]

1: normally support helps with that setup. If that's not enough for you, then please avoid that setup

1+: yes, we saw your feature requests

[bc-109]

1+ : Yes, I already had at least two of my past Feature Requests implemented. That never happened with any of my other hardware/software suppliers in 25 years That's one of the reasons why we take time to explain our problems here : because people understand what we say, and do their best to develop useful new features. Thanks again to all Veeam technical / engineering people

[HannesK]

Hello,
as version 11a fixed many issues, I checked again on sharing Linux repositories between VBR servers and how this influences Hardened Repository.

1) As stated by Anton earlier in this thread: officially we do not support sharing servers / components between different VBR servers. 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). I also tried it out adding one with IP address and another with DNS name. Both works fine.

I hope that clarifies everything.

Best regards,
Hannes

[josues]

Hello

Regarding sharing Hardened Repository Linux repository between different VBR servers.

Does this feature in Veeam v12 still work unofficially?

[david.domask]

Hi josues,

Tested it quick on 12.1.1.56, and indeed it still works. However, please note that such a configuration is still officially not supported (5th bullet point). If you do go this route, please be sure to note the concerns here, and be extra certain that the two servers do not point to the same path on the shared server: https://helpcenter.veeam.com/docs/backu ... ml?ver=120

Consider the following:

• Do not configure multiple backup repositories pointing to the same location or using the same path.

• Do not configure multiple backup repositories with "nested" paths (when one repository path is a sub-path of another repository), for example:

/mnt/repo/backups/
/mnt/repo/backups/production/