Client waiting while merging incr. & full

[Keyser]

Hi

I have deployed a bunch of endpoints against our Veeam repository, and i works really really well

One thing though: I have a few people who generally use their laptops rather briefly while at the office. That's usually not a problem since their incr. backups are in the 4 - 5Gb size.
But the clients spend far more time waiting for the repository to complete the merging of the oldest incr. and the full backup than doing the actual backup.

Since no network traffic is occuring during that wait, I assume it is a proces the repository role performs?
If so, could we have the endpoint client complete the backup when data transfer is complete and let the server complete the merge on it's own schedule?

My clients are typically waiting about 10min at the 99% completed stage while merging is taking place. This is probably because my backup IO capacity is overloaded during the daytime (from other jobs to tape and so forth).

I see no point in the client waiting so long. It increases the risk substantially that clients disconnects before the backup is completed allthough the data transfer is completed long ago.

[Dima P.]

Hi Keyser,
Is the repository in the question a dedicated one for Endpoint backups or regular VBR jobs can use it too? Any chance its a CIFS repo?

[Keyser]

Its a shared repository for VBR jobs and endpoints - well actually it istn't - i have two different repository folders, one for VBR and one for endpoints, but they share the same disks.
Is local storage on the veeam server, so not a CIFS.

[Dima P.]

Got it - thank you! Please check the throttling and repository settings like described here.

[Keyser]

There's no throttling being done, and the backup itself is as quick as I could/would expect given the network conditions.
I'm questioning the need for the client to wait while the server does the consolidation of the oldest backup files. During that period I see no CPU or network usage on the client. As far as I can tell it's just waiting.
Can the client not simply offload that task completely to the server and report a completed job once data is transferred. It's not important if the consolidation is done right away or later on when the server has time. From the clients perspective the only important thing is getting the data shipped of to the repository.

[JaxIsland7575]

Not to interrupt the chain here, but my thought is if you do as you say Keyser and once the last bit is transferred then it completes the job on the client side, what if something is corrupted or fails in the rollup? Once the client side has closed down the job and it reports as successful but the server is still processing the job it could still fail. Now you have a corrupted chain on the repository side and a successful on the client side. This is purely a guess but I would assume VEB is coded so that it can verify the consolidation is completed successfully before reporting the job as complete and successful. My example would be a user is sitting waiting for Veeam to finish and it says completed and successful, so they shut their computer down and leave. Now the server is processing the consolidation and something goes wrong, there is no way the user will know something is wrong until another job fails during the backup or they try and do a restore and find the backup chain is no good. Just my perception on the question you are asking!

[Keyser]

I can certainly understand your argument, but I would also point out, that even though the backup is then marked as failed on the client, the user would still think that "oh, well, i have the many previous days of backup, so I'll survive"

But given that this runs as a incremental type backup, that is not the case. If the merge fails and ruins the full file, all backup is lost, regardless of earlier succes'es. So the failure or success of the merge is more relevant to "recoverabilily" in general than to just the current backup being done. Nothing can save your backup chain if we fail a merge of the old files. So the only argument is if endpoint backup at a merge failure actually states that all backups are corrupt, and that you need to start over from the beginning. I haven't tested if it actually does that.