I'm tryng to backup a SQL instance with more than 300 DB on one DDBOOST device.
I'm using the MSSQL: saveset but i can see that i've about one job for one DB in the running portion of the job, at the same time.
This mean about 300 parallel stream, with obviuously poor performance.
On the client the parallelism is set to 16, but networker seems to ignore this limitation.
The nw server, client, and module version is 8.2
How can I limit the parallelism of this job?
What is setting for the "Stripe" for the SQL backup?
Alternatively can you run a Manual Backup from the SQL server using "NetWorker User for SQL Server" and check the performance
I believe the strive setting is not proper in your case.
We are using nw8.1 + nmm3, but we were also unable to resolve such problems. I think client parallelism works only if you have many savesets in the client definition, but now you have only one (MSSQL:).
A simple workaround is to create more clients with specific (MSSQL:db1, MSSQL:db2,...) saveset definitions and run them in separate, not overlapping groups. The drawback of this solution is if something changes in the environment (add/remove db) then you should not forget to change the backup config.
I know that, we've this issue since we've modified the SS from MSSQL:blabla to MSSQL:
BTW we cannot mantain the specific SS for every db because on this instance there is more than 300 DB with high chance of change.
SQL VDI backups are quite touchy so if you reduce available targets, they tend to fail so limiting targets might not be welcome. And in general it would mean to have dedicated devices for SQL backup which translates to additional pool so suddenly whole setup changes. Real solution should be to implement change on client code side.
NMM doesn't care of parallelism limitation set in Networker. We have seen the same with Exchange Backup.
The only way will be to limit the number of save stream on Storage Node (even if it's not ideal) or create many different client with different Save set.