Another good question. Once I have my groups structured I then try to balance the clients out based on time slots around the backup window. Of course some people dictate what time they want a client to run but not many.

So for example, we would have Production kick off earlier and Integration (QA) and Development later. This makes logical sense of course because you probably want your PROD done ASAP before next working day so give it a bigger window.

So lets say PROD kicks off at 6PM, which is the start of your backup window and lets make this easy, you could have a 6PM, 7PM, 8PM, 9PM , 10PM ..... groups, you get my point, then carve your clients into these groups.

I always think it's good to modularize your groups and evenly spilt across them, rather than large groups top down, again purely ease of manageability of your groups, especially starting and stopping but also to try and evenly distribute the workload out.

J

I think this is a great idea. I was also thinking about naming them via time like

"6PM"

"13:00"

Or something like that, as the groups tend to be the springboard for the backup time start.  But in your experience, how does networker handle a large number of servers within one group? Will it big it down?

That actually is not such an easy question to answer as it really can depend on your environment.

Through experience I have found it nice to split by O/S and also by server use with the time in there. For example:

"Windows DEV 19:30"

"Unix PRD 20:00"

"Exchange QA 21:10"

Dev=Development, PRD=Production, QA = Quality Assurance, you could throw in "TST fot test

You get the idea, you could go further for easier manageability at your site and add server "application". The reason for this, if you don't have DPA it will make NMC reporting easier based on your group criteria. Also I think the more descriptive the group name the easier to see and manage at a glance.

J

I don't think large groups will bring it down as long as your servers can handle the work (NetWorker Server / Storage Nodes) but as I'm leading to, evenly distributed groups brings you easier manageability. I see what your thinking with your spring board approach,  it's a trade off.

Its sensible to come up with a naming policy as this means you can figure out how groups are configured and what clients are contained by looking at the name.  You need to arrive at a naming convention based upon your environment, ideally you want to look at your groups having more than 5 clients and less than 20 clients and evenly spreading load across your backup window.  Some factors you can use to group your clients:

• Location
• O/S
• Department
• Dev/Prod
• File system or application
• Day of full backup
• Start time

We configure our backups by the amount of time we need to save the tapes in off-site storage. Pools are also named with the same sort of scheme. Thus, we have names like Prod_SQL_7 for production SQL databases that need to be saved off-site for 7 years. That helps us with our expiration management as well, since I can sort the off site tapes by the pool name and get a handle on which ones we need to bring back from off-site. The start times are re-arranged a little so we don't have too many jobs waiting for a tape drive (we have two). Hope this helps.

Using a naming convention consisting of below details would help you in Tape management/ Backup startup/restart on failure /Prioritize according to the server usage.

• Daily or Weekly
• Server use(Production or Develompent)
• Type of Backup(Filesystem or Application)
• Start time(considering the fact that production servers Backup should not be started in Business hours)
• Retention of Backup

Eg. Daily_Prod_Oracle_9PM_7D

where 7D stants for 7 days.

Defining Start time and use if server in the group name will also help you decide wether the group can be restarted in day time if some savesets fail for this group.

I'm all about simplicity. Keep the number of groups to a bare minimum. In fact I will throw something out there that might sound like crazy talk. How about just ONE group? I know to a lot of us who have been in the backup space for a long time we have traditionally broken up OS, but really why? Things we should be more concerned about are mixed retentions on tape. But really there is not reason why NIX/WIN cannot be in the same group. Media selection can be controlled by variables on the media pool. I would probably keep NDMP and DB's seperate.It's something I've been thinking about as the NetWorker Env I've inherited has a lot of groups. Will a large number of queued jobs slow the system down? I dont think so as long as you meet or exceed the minimum reqs.

One problem with this approach is that starting a backup puts a memory and processor load onto your backup server; in some cases starting a large number of backups simultaneously may cause your backup server to crash.  You also miss the benefit of scheduling backups across your backup window to spread load, minimize multiplexing (which would extend recovery time) and avoid backups potentially queueing for long periods and potentially timing out.  There will also be times when you would need more than one client instance to meet your backup requirements for a host (for example backing up application and file system) which would necessitate a second group.

Yeah, I hear what you are saying. I'm not suggesting we have to many jobs writing to tape or disk. That will still be controlled. Any jobs that do not have resources will queue until a resource becomes available. The question is what is the cost of a queued job? Not a running job.