Comprehensive data protection for all workloads
Post Reply
JensH
Service Provider
Posts: 3
Liked: never
Joined: Dec 11, 2020 3:08 pm
Full Name: Jens
Contact:

Preferred network per client

Post by JensH »

Hello,

We have at customer site a complex network infrastructure. The have a lot /26 networks and for every /26 network a separate backup network without a gateway.

At the moment every VBR and repository server has a network configured with an IP in every backup network.

With VM’s there is no pain for backup and full recovery. Every other action like file recovery, backup/restore physical servers, agent backup/restore is a problem.

Each configured IP on the VBR/Repository Server is tested on every job sequentially until the correct IP is found. That leads to very high timeouts and delays, at the moment up to 45 minutes delay per job, on RMAN backup this delay is for every datafile. It is possible to configure a global preferred network for backup. Our problem is we need a lot of preferred networks ……

Is it possible to add a preferred network for every VM/physical server?
Is it possible to configure it in the client/agent?

If not, is it possible to raise a feature request?

We also have a support request opened #04532596

regards
Jens
PetrM
Veeam Software
Posts: 3624
Liked: 608 times
Joined: Aug 28, 2013 8:23 am
Full Name: Petr Makarov
Location: Prague, Czech Republic
Contact:

Re: Preferred network per client

Post by PetrM »

Hi Jens,

The feature request is noted but I cannot comment on ETA because it's hard to say now in which release cycle we can start to implement it.

I would also recommend to keep working with our support team in order to understand the root cause of timeouts and possible ways to get rid of them. Probably, it would be possible to tweak some specific settings in OS or at the level of related network equipment. For example, you could try to use NAT on the database server to translate the "wrong" IP to the correct one:

Code: Select all

iptables -t nat -A OUTPUT -p tcp -d <"WRONG" REPO IP> -j DNAT --to-destination <CORRECT REPO IP>
Please keep in mind that this is just an idea of potential workaround which must be carefully tested at first.

Thanks!
Post Reply

Who is online

Users browsing this forum: veremin and 297 guests