How to count all backup sessions in some specific (night) time

You can get session counts from nsradmin

show statistics

print type:nsr

and take deltas every of your choice

Throughput might require some thought depending if you want it per drive or via some other criteria.

For example, again in nsradmin

show session statistics; session client name

print type:nsr

might give you useful point in time information that you can collate/average over a period

Jason.

Hello,

Report NMC you can use to generate all kinds of information you need.

Regards,

Hi,

have a look at our website

http://www.schaefer-tobies.de/products/ST-Perf/EN/

May be that is what you are looking for.

Peter

As stated above easiest way would be to use NMC reporting tool. you can play around a lot with those. Transfer rates can be gotten from the drive reports.

When creating default reports keep in mind that when setting the date and time, you can also just set them as you do in mminfo, 1 day, yesterday, etc.

Thank you for your support and for the provided suggestions. I've tried to use NetWorker repots tool and also

mminfo as  suggested, but unfortunately I cannot find the correct way to get required information.

For better understanding here is one example.

I need to know how many backup sessions were running during the last night backup between 00:00 and 03:00 am.

Explanation:

We have one backup group (INCR) for incremental backup with 150 client’s in it. This group is starting at 6:00 pm daily.(Because of Incremental backup, almost all servers are backed up in next 2-3 hous) At 10:00 pm some more groups are starting for daily full backup, at 00:00 next backup (FULLx) group starts with the client wihch "savepnpc".running as a backup command.

On next day I can see that the all groups were starting as scheduled, also the group with the clients that are running savepnpc command. But executions of savepnpc scripts on the client machine happened not at 00:00 then some times at 01:30 sometimes at 02:30 etc…

Therefore, I need to know why the backup of this group starts sometimes with delay but alsosometimes on time. (Scripts on client’s side are checked and OK)

Users from monitoring shift are reporting that FULLx group is triggered at scheduled time, but the clients in this groups are just pending for a 2-3 hours with status “contacting client” .

Log files are also showing the same, backup group started at 00:00, but the execution of savepnpc script on client side happened sometimes at different time mostly immediately as the FULLx group is started but sometimes also 2 hours later.

Both groups FULLx and INCR are using same Media Pool.

Vucko,

I have read through your posts and have the following comments: -

1. Your NetWorker server parallelism is max value of 64.

2. You start a group with 150 clients in and this runs for 3 hours and finished before the next group starts at 22:00.

3. You then start multiple groups (no client figures) between 22:00 and more again at midnight.

4. I think your issue is simple. The group you are starting at 22:00 is consuming all of the parallelism for the NetWorker server until around 01:30 - 02:30 backing up the clients contained within it. The default client parallelism now is 12 therefore it would only take 5 clients of the 150 you start (providing they have 12 partitions, system savesets) to exhaust bar 4 all your available sessions. Any which are extra over 64 are put "on hold" or "pending" until a session is available. Actual sessions starting assuming 12 is 1800, assuming 4 (old default) is 600 a lot more than you can handle!

5. Other sessions would then be fed in as individual current sessions of the 64 complete, and you then add to the "pending" list at midnight by starting another group which then waits until the current + all the pending to that point are below 64 in total. They can then start to run and do as the group wants (firstly running the savepnpc scripts).

6. You are making the NetWorker server work harder than it needs to as it has to manage all these sessions even though only 64 can run at once.

7. So you can either: -

a. Spread the load of the groups and create more and spread them throughout the backup window ensuring you have less than 64 possible sessions at any one time.

b. Introduce group parallelism which will allow only say 20 sessions from a group concurrently allowing overlapping groups to get some resources and start more timely.

c. Work out how long the 22:00 group needs to complete running as is and move the midnight group to after this.

8. If for some reason the midnight group time cannot move then cut the number of clients in the 22:00 group so it completes before and create a new group starting after 00:00 group is finished or close to finishing.

9. It’s a timing issue you have and you can work all of this out without a report from NW and adjust as your environment changes.

10. Other factors are network bandwidth to the storage nodes (including NetWorker server) for many clients could also cause the throughput to drop as network throttling would come into play. Available devices and multiplexing - you will get far more multiplexing on 4 drives than 10 or 20 for 64 sessions even though you use the same pool. This can delay recovery of data and issues on the drives depending upon the file sizes you have.

HTH

Bill Mason

Looking at Bill's post, I think he has hit the nail. parallelism at 64 and 150 clients will cause a lot of issues.

If you just want to see how many savesets are running on your system, try doing a cron job every 2 to 5 minutes checking the number of nsrexec processes on the backup server (ps -ef|grep nsrexec\ |wc -l should do the trick and then post that number and a timestamp to a log file). If you have some shell scripting skills it should also be easy to select this number for each specific host and such.

The fact that your precommand does not always start at 00:00 will be caused by the client parallism being at max at the time the group starts. This is then of course caused by the number of savesets being higher than the server parallelism.

Follow Bill's instructions on setting up your savegroups correctly and you should be fine.