I’ll start this by saying that I used to be an out-and-out Unix bigot, and would still classify myself as strongly preferring Unix over Windows.

So when I’m asked “what operating system should I deploy my NetWorker server on?”, I tend to have to bite my tongue to not immediately respond with say, Solaris*.

The truth is, there’s only one answer to this question: the most appropriate operating system to your environment. This may sound like I’m sitting on the fence, but that couldn’t be further from the truth. Your backup server should be based on your operational strengths. That means if you’re have a completely homogeneous environment comprising only of Windows machines, then clearly the choice should be a Windows NetWorker server. If you have a purely Unix shop, you should deploy a Unix NetWorker server.

But what if you’re a mixed shop?

Traditionally one of two things happen in a heterogeneous environment:

  1. In an “average” sized environment with Unix and Windows system administrators, usually one team will deploy workgroup style backup environments while another will deploy an enterprise package. I’m not sure why this happens, but it’s not often you see enterprise packages deployed by both groups. In this case, the NetWorker server should be consolidated to the current enterprise environment.
  2. In larger environments, there should be a storage and data protection team that includes both Unix and Windows system administrators. In this case, that team should evaluate the unique needs of the environment and pick the most appropriate OS for the backup server on the basis of the overall system administration strengths and compatibilities of the organisation.

I know this sounds like a wishy-washy answer, but the point I’m wanting to make is that the choice of operating system for the backup server shouldn’t make a difference, and for one important reason: NetWorker scales far beyond just using a single backup server. Thus, rather than getting hung up on choosing between Windows or Linux or Solaris or AIX or HPUX (etc.) for the backup server, be prepared to scale your environment to suit.

For instance, I periodically get told, “We don’t want to deploy Windows as the backup server because the environment will get really big.” My response to this is simple: in a really big environment, the backup server should be in an executive role only, simply coordinating backups and handling indices and media databases, with all backups being handled by storage nodes**.

So if you want to know what the best backup server is to run NetWorker on, it’s whatever suits your environment with the caveat – be prepared to scale beyond just a backup server and clients.


* Alas, I’m not able to respond Mac OS X. There’s not even a storage node for this platform.

** Yes, I know that the backup server must at least be able to do its own bootstrap backups – and for what it’s worth, I agree with this requirement.

 

I can’t stress the importance enough of getting your bootstrap reports offsite. If you don’t have a bootstrap report available and you have to rebuild your NetWorker server, then you may potentially have to scan through a lot of media to find your most recent backup.

It’s all well and good having your bootstrap report emailed to your work email address, but what happens if whatever takes out your backup server takes out your mail server as well?

There’s two things you should therefore do with your bootstrap reports:

  • Print them out and send them offsite with your media – offsite media storage companies will usually store other records for you as well, so there’s a good chance yours will, even if it is for a slightly extra fee. If you send your bootstraps offsite with your media, then in the event of a disaster recovery, a physical printout of your bootstrap report should also come back when you recall your media.
  • Email them to an external, secure email address – I recommend using a free, secure mail service, such as say, Google Mail. Doing so keeps electronic copies of the bootstrap available for easy access in the event of a disaster where internet access is still achievable even if local mail isn’t possible. Of course, the password for this account should be (a) kept secure and (b) changed every time someone who knows it leaves the company.

(Hint: if for some reason you need to generate a bootstrap report outside of the regular email, always remember you can at any time run: mminfo -B).

Obviously this should be done in conjunction with local storage methods – local email, and local printouts.

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha