NetWorker Blog

Commentary from a long term NetWorker consultant and Backup Theorist

  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Enterprise Systems Backup and Recovery

    If you find this blog interesting, and either have an interest in or work in data protection/backup and recovery environments, you should check out my book, Enterprise Systems Backup and Recovery: A Corporate Insurance Policy. Designed for system administrators and managers alike, it focuses on features, policies, procedures and the human element to ensuring that your company has a suitable and working backup system rather than just a bunch of copies made by unrelated software, hardware and processes.
  • This blog has moved!

    This blog has now moved to nsrd.info/blog. Please jump across to the new site for the latest articles (and all old archived articles).
  •  


     


     

  • Twitter

    Error: Twitter did not respond. Please wait a few minutes and refresh this page.

Basics – No two groups should start simultaneously

Posted by Preston on 2009-03-26

One of the most common configuration issues I see is where multiple NetWorker groups are configured to start simultaneously. For example, you might see a situation where say:

  • Daily Servers
  • Monthly Servers
  • Yearly Servers

All start at the same time. A common response when I express concern over this is “even though they all start at once, only one group will ever be backing up”. (I.e., skips are deployed appropriately.)

This isn’t sufficient.

Starting multiple groups simultaneously cause what I like to refer to as server spikes. That is, sudden, sharp increases in server resource usage. By ‘resource usage’, I’m not necessarily referring to memory and CPU, though that can occur, but by internal NetWorker communications and resource usage.

When server spikes occur, odd things can happen – albeit randomly and often intermittently, but they can still happen. Savesets might unexpectedly drop communications with the server and need to be restarted (or worse, hang, then continue once a second saveset for the same client/data is started by the server, creating load on the client); a single media load instruction might fail, or a single nsrmmd process might get timed out and restarted.

There’s an easy solution for this, and one which everyone should follow:

Never, ever, have more than one group start at the same time.

You don’t have to have a big gap. I’ve typically found that 5-10 minutes is an ample gap. If each group starts on its own, then the server behaves considerably more smoothly, and less weird intermittent/random failures occur. (If your response is that your backup windows don’t allow a five minute gap between groups, I’d reasonably confidently argue, even having not seen your site, that your backup configuration needs to be re-evaluated.)

Advertisements

2 Responses to “Basics – No two groups should start simultaneously”

  1. Daniel King said

    Thank you! I never thought of that but it makes total sense. I only only hope I can remember it next time I design a Networker solution, then again, it tranverses most backup products doesn’t it?

    • Preston said

      It depends on the architecture of the other products. In general though I would agree that splitting start times by even a few minutes for other backup products can’t hurt (even if it does turn out to not be wholly necessary).

Sorry, the comment form is closed at this time.

 
%d bloggers like this: