I usually see people using a lot of groups, sometimes with no more than 3 different clients. It's a lot easier to manage in the case one client fails, the group can be restarted without waiting a lot of other clients to finish (considering the problem was fixed). Groups with no more than one client is usual.
Of course Nw provides a lot of ways to group things, this is just one I see often.
We tend to group similar clients together, as we use different pools for different operating systems and it avois some drive contention issues. Any failed clients are pulled into a retry group for re-running.
I've always stuck to teh rule of thumb that 64 clients per goups should be the maximum.
I use groups to group clients based on their role (which also determines window in which group runs) and function. From that point of view I have file system backup groups following naming convention like:
I have two special groups; index and ONE_OFF which are self explainable.
Each FS and ARCH groups has 10 clients as minimum. Each client will have schedule like Full_on_$Day_rest_... where day is Mon to Fri thus group will always run with 2 clients having full backup and rest incremental.
TST&EDU I run in morning until noon, ACC in afternoon, PRD and DEV in evening. Exceptions to rule are PowerSnap based backups.
Such simplified usage of groups made enterprise environment I manage at the moment work without any issues. It also simplifies management and proactive checking.
Thank you everyone for the input. I was looking for a pattern in the way groups are used. Turns out there is no real pattern. Another example of how you leverage the flexibility in NetWorker to creatively solve problems. I appreciate the feedback.
We are in the camp who put 1 client definition into each group, and allow groups to be run through an external scheduler.
This means that each individual backup is treated as a batch job by our 24x7 support groups, and if it fails then they are able to act upon that individual failure almost immediately. OK, they may not be able to resolve the problem, but in many cases they can, and by the time my alarm clock goes off in the morning, they have cleared most of the issues that have occurred in our setup overnight.
We often get asked to revisit the use of the external scheduler, and 1 client definition per group. The response that I always get back from my support people is that we need to keep things simple for them where possible. I have enough issues where they stop filesystem backups from running again because just 1 filesystem has got something corrupt in it - as Siobhon says restores are the reason we do backups, if I've managed to back up 90% of a box, I have at least got a flying chance of restoring a file when requested - if support stop the batch job because 1 part of it fails then we've got no chance.
So 1 client definition per group raises our probability levels of getting more successful backups.
There is the other option of improved training for the 24x7 support teams, but ...
gcua
6 Posts
0
May 25th, 2010 08:00
We use groups for a specific subset of servers we need backed up.
For instance, all webservers would go into a group
sql servers would go into one
We don't really mix backup types in the same group.
Isaac
dpinink_silva
2 Intern
•
724 Posts
0
May 25th, 2010 11:00
I usually see people using a lot of groups, sometimes with no more than 3 different clients. It's a lot easier to manage in the case one client fails, the group can be restarted without waiting a lot of other clients to finish (considering the problem was fixed). Groups with no more than one client is usual.
Of course Nw provides a lot of ways to group things, this is just one I see often.
Philc3
7 Posts
0
May 26th, 2010 00:00
We tend to group similar clients together, as we use different pools for different operating systems and it avois some drive contention issues. Any failed clients are pulled into a retry group for re-running.
I've always stuck to teh rule of thumb that 64 clients per goups should be the maximum.
ble1
4 Operator
•
14.4K Posts
0
June 3rd, 2010 10:00
I use groups to group clients based on their role (which also determines window in which group runs) and function. From that point of view I have file system backup groups following naming convention like:
[NDMP|FS]_[EDU|TST|DEV|ACC|PRD]_site_[local|remote]_counter
Then we have database groups (one group per database sid):
[ORA|SAP]_DB_[EDU|TST|DEV|ACC|PRD]_site_[local|remote]_counter
Then archive logs:
[ORA|SAP]_ARCH_[EDU|TST|DEV|ACC|PRD]_site_[local|remote]_counter
I have two special groups; index and ONE_OFF which are self explainable.
Each FS and ARCH groups has 10 clients as minimum. Each client will have schedule like Full_on_$Day_rest_... where day is Mon to Fri thus group will always run with 2 clients having full backup and rest incremental.
TST&EDU I run in morning until noon, ACC in afternoon, PRD and DEV in evening. Exceptions to rule are PowerSnap based backups.
Such simplified usage of groups made enterprise environment I manage at the moment work without any issues. It also simplifies management and proactive checking.
SkipHanson1
21 Posts
0
June 4th, 2010 07:00
All,
Thank you everyone for the input. I was looking for a pattern in the way groups are used. Turns out there is no real pattern. Another example of how you leverage the flexibility in NetWorker to creatively solve problems. I appreciate the feedback.
Cheers,
Skip Hanson
NetWorker Usability
fparsons1
15 Posts
0
June 24th, 2010 11:00
Hi Skip,
We are in the camp who put 1 client definition into each group, and allow groups to be run through an external scheduler.
This means that each individual backup is treated as a batch job by our 24x7 support groups, and if it fails then they are able to act upon that individual failure almost immediately. OK, they may not be able to resolve the problem, but in many cases they can, and by the time my alarm clock goes off in the morning, they have cleared most of the issues that have occurred in our setup overnight.
We often get asked to revisit the use of the external scheduler, and 1 client definition per group. The response that I always get back from my support people is that we need to keep things simple for them where possible. I have enough issues where they stop filesystem backups from running again because just 1 filesystem has got something corrupt in it - as Siobhon says restores are the reason we do backups, if I've managed to back up 90% of a box, I have at least got a flying chance of restoring a file when requested - if support stop the batch job because 1 part of it fails then we've got no chance.
So 1 client definition per group raises our probability levels of getting more successful backups.
There is the other option of improved training for the 24x7 support teams, but ...
Felix