Best Practice – Groups

There’s a few very important rules to follow when it comes to NetWorker groups:

1. Maintain an air-gap: Ensure there’s at least 5, preferably 10 minutes, between the start time for any two NetWorker groups. This even includes groups that won’t run due to schedules. (E.g., a Daily group, and a Monthly group for the same data should not start simultaneously even if only one of the groups will ever actually be backing up at once.) Multiple groups can overlap, of course, but they must not start at the same time.
2. Client/group ratio is important: While the NetWorker performance tuning guide suggests a maximum of 50 clients per group, it’s a little more complex than this. The more clients you have in a group, the more likely you’ll be to need large server resources (e.g., much more RAM in the server) or to use group parallelism to limit the number of clients that can start simultaneously. Equally, avoid having lots of groups with few clients in them where possible. (E.g., if you have 100 clients, it’s better to have 4 groups of 25 clients than say, 10 groups of 10 clients each.)
3. Group parallelism should be used more regularly: A typical rule of thumb is that if numClients x sum(client parallelism) for a group exceeds the parallelism of the NetWorker server, you must use group parallelism to limit the number of savesets, and if it exceeds around 150 units of parallelism, you should use group parallelism, regardless of what the server parallelism is.

While not “official” EMC recommendations, after 16+ years of using NetWorker, I’d also suggest the following should be considered rules, too:

1. Never name a group based on its start time: You call the group “2245 Daily Servers”. Sounds like a great idea, until you need for some reason to alter the start time to 22:15 instead.
2. Don’t mix filesystem and non-filesystem backups: Wherever possible, keep non-filesystem backups in their own groups. E.g., have a “Daily Filesystem” and a “Daily Databases” group, and so on. Definitely avoid having a module backup and filesystem backup for the same client run in the same group.
3. Don’t mix retention times: If you do data/pool allocation by group, set all clients in the a group to have the same retention time.
4. Don’t set inactivity timeout to 0: An inactivity timeout of zero means the group will never timeout, and therefore may never complete if ‘hang’ conditions happen. If you insist on having a zero-timeout on a group, only do so if you’ve got another process watching and alerting on the group running for too long.
5. Avoid high client retries: The normal client retries for a group is 1, meaning two attempts will be made on any saveset. Be careful at increasing this beyond 2 (3 attempts) – savesets that sensitive may need to be monitored externally instead.
6. Use comments, not elaborate names: Don’t try to put all the details about the group in the name, which you can’t change later. Instead, keep the group name as simple and generic as possible, and if additional information needs to be annotated for the group, put it in the comment field, which is displayed in NMC.