veeam.ini param to specify interface or address?

[mikeely]

I'm trying to backup a machine with fairly complicated networking and need to override the default route to the backup target. I can't set a default route on the agent machine because complicated. I could go into how specifically this is complicated and why I need to do this but it involves a particularl combination of vps, freebsd firewalls, packet mangling, etc. These are weeds you probably don't want to go into...

Anyway, I was hoping there would be a directive in /etc/veeam/veeam.ini that would say "address 1.2.3.4" or "interface eth1" or similar to explicitly tell the Veeam agent to only use that interface. I don't see one and couldn't find such a directive in the docs either. Is it there and just not documented?

Thanks in advance.

[PTide]

Hi,

Nope, there is no such setting in veeam.ini. The request has been noted. However, without a detailed explanation it might be quite challenging to make it happen : )

Thanks!

[mikeely]

What I'm thinking of is similar to the Apache directive "Listen 1.2.3.4:80"

Something like "DataMover 1.2.3.4" or "DataMoverInt eth1"

[PTide]

I get what you mean, but what's your scenario? If the agent and VBR/repo are in different networks then it should be handled by VCC. Or at least you could use "Computers with pre-installed agents" Protection Group type.

I mean, we certainly could add that directive, we just would like to know why : )

Thanks!

[mikeely]

Basically this particular host has some VMs, one of which is a firewall protecting that host, which is enabled by a static network route on the host - I said it's complicated and I did not (would not) build this thing. The consequence of this is that traffic coming in to the physical host comes out on a different IP address, which Veeam correctly ignores as a Martian. What I was looking for is a config var that says "use this interface" or "use this IP address" no matter what the routing table says to use.

[aj_potc]

I don't mean to hijack the thread, as I find this a potentially useful option for the Veeam agent to have.

But what do you mean by:

If the agent and VBR/repo are in different networks then it should be handled by VCC.

I can hardly think of any business that doesn't have resources distributed all over the place these days. It doesn't make sense to set up local backup repositories at every location. Is it really true that the only official way to back up those remote resources is through Veeam Cloud Connect? What if I want to provision and maintain my own off-site repositories and not rely on a dedicated backup service provider? I know that this can be done with Veeam -- I've done it several times. I'm just surprised to hear that it's considered as a special (and unsupported??) case.

Thanks for any insight!

[PTide]

Is it really true that the only official way to back up those remote resources is through Veeam Cloud Connect?

Right. Agents cannot work with VBR if it's behind NAT:

Veeam Agent for Linux should be able to establish a direct IP connection to the Veeam Backup & Replication server. Thus, Veeam Agent for Linux cannot work with Veeam Backup & Replication that is located behind the NAT gateway.

Next, onto your second question:

What if I want to provision and maintain my own off-site repositories and not rely on a dedicated backup service provider? I know that this can be done with Veeam -- I've done it several times.

Then you know what to do! : ) Jokes aside, we've seen similar requests before, and we are already figuring our how to address the issues in the best way possible.

Thanks!

[aj_potc]

Thanks for your reply.

Well, the NAT issue isn't too difficult to sidestep -- you just need the Windows VBR to have a routable IP. Again, it may not be the "official" way, but it works.

I think the core issue, which others including the OP have mentioned, is the desire by many of your clients to have their repositories on different, firewalled networks. And I prefer my repositories to be in a different physical location, too. I like using my own infrastructure for this, as I can do it far more cheaply, with more oversight, and probably with more redundancy than is possible with the providers I'd be using through Veeam Cloud Connect.

I'm not sure why this is an unsupported configuration, but I'm glad it's an issue you're looking at.