In the NetWorker client resource, there is a parameter called "Server Network Interface" (SNI).   Please populate this field with the i.p. address of the backup server...  specifically, the i.p. address that you want your client to use to send backup data to the backup server.

This will force the client to communicate with the backup server via that SNI address.  There will still be some traffic using the public address but if you are using the backup server as the storage node, the actual backup data will be sent through the network connecting to the SNI address.

If you are backing up data to a ddboost device, then Client Direct will allow the client to send data directly to the ddboost device, but the metadata will still go to the backup server.

Hello Wallace,

Thanks for your input.

indeed this was the issue with "Client direct" for testing purpose i disable the client direct backup on one of test device and after that client start using the backup vlan for backup.

Best Regards

Sukhdeep

You can make the NetWorker client send Data on Backup VLAN without loosing Client Direct capability by adding Storage node entry same as that of SNI and use the device from the Backup VLAN on DD to be used as a Backup device for this client.

Hi,

There are many considerations using a dedicated backup VLAN. (hostnames, aliases, magic dns issues, all backed up hosts will be connected to each other if you use a simple vlan without (network infra) firewalling possibilities, etc..).

Are you doing many restores in your environment? If you are using a DD backup should not generate much network traffic because of the client side dedup.

If you want to have a separate vlan, I don't see why do you keep your DD in the prod net, your traffic will go trough a gateway.

Isn't the "new" ifgroup feature from DataDomain a good aproach for separating the backup traffic to a backup VLAN?