Data Domain Boost Client data path - direct to DD?

[stevekarra]

I noticed that the Veeam agents for at least v12.1, and even plug-ins for apps like MS-SQL, include DD Boost and other 3rd party libraries.

But when backups are performed, I observed that the clients write their backups via the backup/repository with gateway server/service and not directly to Data Domain.

Is there a way to force a direct data path from the client to the data domain for data (not metadata) transfer? If it's not supported today, is it something that might be a roadmap item?

[Mildur]

Hi Steve

DataDomain for Agent requires a Gateway Server. Agents cannot directly use DDBoost to write to the DataDomain.
May I ask, where have you seen the libDDboost.dll file on an agent? I can't find it on two of my agent installations.

libDDboost.dll gets deployed with our transport service if you add a machine as a proxy, repository server, gateway server or managed file server.

Best,
Fabian

[stevekarra]

Thanks Fabian.

It was deployed as a managed file server, so appears in the usual place - C:\Program Files (x86)\Veeam\Backup Transport\x64\ddboost. I also noticed it on an SQL Server that is being protected by the plug-in, although I can't be sure that I didn't also deploy the agent from the backup server on that.

Can I deploy the gateway service on that client to get what I'm looking for?

[stevekarra]

I think the problem is that the gateway selection is configured on the DD repo on the backup server. If I use the SQL server as the gateway, it will send backup data directly to DD (as I'm looking for) but then all the other clients that want to write to DD will inherit that gateway setting and also attempt to use the SQL server as the gateway. So they will now have the data path client->SQL->DD.

So perhaps a limitation on the way Veeam is architectured today?

[Mildur]

Hi Steve

You can make the agent a gateway server, but in such case other agents will use the same physical machine as well as the gateway server. I don't recommend doing that.

So perhaps a limitation on the way Veeam is architectured today?

I wouldn't call it limitation. It's expected behavior (how it was designed).
The agents will use the gateway server provided in the Data Domain repository settings.
It's how it works today.

Do you see a specific issue with that design? I can forward it as a feature request. Agent directly communicating with Data Domain.
But I want to understand first what issue you see with the current design.

Best,
Fabian

[stevekarra]

Thanks for the feedback Fabian.

Yes - for scalability and to reduce network traffic, it would be very desirable to have the ability for each client to act as it's own gateway server to a central Data Domain. Currently it's set on the DD which then affects ALL clients so they have that single gateway setting.

Perhaps an additional setting on the repo that would provide for the local client choosing the gateway server (itself) if applicable, and falling back to the centralized setting if it weren't functioning as a gateway?

[mickey.friedman]

Case for Agent Direct with DD is pretty straight forward:

1. Less data would be travel on the network, each agent will transmit only the necessary blocks directly to DD.
2. Amount of Compute and RAM resources on the gateway will not be an issue, since each agent will use its own resources to compute/query the DD
3. Restore will be much faster !! Since DD will communicate directly with the agent removing a hop.

BOOST stands for Backup Optimized OST, with Veeam's implementation of it all the transfer optimization that was at the heart of BOOST development is moot.