Long restore via API TCP Handling

[mjr.epicfail]

Hi,

Case: 08028895

We have our own multitenant VB365 environment which communicates to VB365 via the rest api.
Between those 2 components there is a firewall to protect DMZ and Internal services.

To export items we use a POST request to restore the items from the backup repository to a temp location on the VB365 server and that then gets streamed as a binary over the same request.
However, bigger exports require more time, and during that time the TCP sessions with the POST is still open, idle, waiting on a response from the VB365 server.
If this exceeds 60 minutes our firewall will remove that connection from the session table what will result in a broken TCP session. Neither endpoints will know this.

I know this is not a situation that happens daily however to keep a POST request open that long is something you would like to avoid for several reasons.
Is it an option to change / add an endpoint that allows this to be handled Asynchronously ?

[tomsinner]

You’re right! Keeping a long-lived POST request open for large exports is fragile, especially with firewall timeouts in segmented environments. An asynchronous, job-based approach would be far more reliable and scalable for handling these operations.
Geometry Dash

[kristofpoppe]

Is there already a Veeam validated solution to this ?

[Mildur]

Hi all

I don‘t have details yet, but I got the information this morning that our teams are looking it to building async API endpoints.
There is no ETA we can share today, it won‘t be included yet in the upcoming update v8.4.

Best,
Fabian