Nomenclature

In the course of the blog I’m referring to a lot of standard NetWorker terms, and I thought it was time I start having a “dictionary” page about those terms.

(Where possible I’ll try to keep this organised by an alphabeticised hierarchy.)

Control Zone

A control zone is a collection of one or more of the following types of hosts, and one or more NetWorker datazones (see further below).

NetWorker Management Console Server

This host runs the NetWorker management console server processes – gstd, the Sybase iAnywhere database and the web services. Users will “point” NetWorker management consoles to the NMC Server in order to administer servers within the control zone.

License Manager Server

A license manager server is a host that licenses may be centrally entered into, and farmed out to one or more datazones. They can allow for more cost effective sharing of licenses between datazones, though there are caveats – some licenses may not be properly processed if served out of a license manager host. That being said, they provide excellent centralisation. They also allow you to have licenses authorised to a machine other than the backup server. If the license manager server is then virtualised, it can be moved around as necessary, keeping the same hostid, and the NetWorker server(s) that source licenses from it will continue to grab licenses as necessary, regardless of their individual hostids, etc.

Datazone

A datazone is a collection of one or more machines that are protected by a single backup server. A NetWorker datazone comprises of three tiers of machines, with these tiers outlined below:

Server

This is the host that actually coordinates/schedules the backups, facilitates recoveries, and maintains the databases relating to configuration, media and client file indices. You only ever have one server per datazone. (While overlapping datazones can be defined where one backup server backs up another backup server, the server being backed up is a client to the other datazone. Note that such a configuration doesn’t see the bootstrap information backed up to the “remote” datazone.)

Storage Node

A storage node is a host within a datazone that can store and retrieve data on behalf of itself or potentially other clients. While backup and recovery operations are still coordinated by the backup server, the actual data stream will run directly between the client and storage node.

There are two classes of storage nodes – a dedicated storage node is one that can only store and retrieve its own data. Such storage nodes are useful when only one or two machines within a datazone have a significant amount of data on them. A regular storage node is one that can store/retrieve data for itself and other clients.

The backup server is always a storage node.

Client

A client is any host that is backed up (protected) by the backup server in a datazone. Clients receive instruction from the backup server as to when they should start backing up, and contact the backup server when it is time to do a recovery. The backup server will coordinate access to storage node(s) for the purpose of the operation.

Storage nodes and backup servers are always clients as well.

Processes

(or “daemons”, if you wish).

nsrd

The nsrd process is the master process within NetWorker. You should only ever find it running on the backup server itself.

nsrjobd

This is the NetWorker jobs daemon, which was hived off as a separate process in NetWorker 7.3. Previous versions of NetWorker saw nsrd handling these activities. The nsrjobd daemon is responsible for kicking off and monitoring running jobs for NetWorker client backups – thus you could say it is responsible for coordinating the activities of the “save” related binaries – save, savegrp, savefs, etc.

nsrmmd

This is the “NetWorker media multiplexor daemon”; it is directly responsible for coordinating the assembly of data that will flow to an individual volume, regardless of whether that is disk or tape. You should see one nsrmmd process per tape device, and two for ADV_FILE devices (one handles the RW device, the other, the RO device).

nsrlcpd

Inherited from Legato SmartMedia, nsrlcpd is the new library control daemon. In previous versions of NetWorker, nsrjb was a very serial process – you could not queue multiple operations. By moving library control to a daemon rather than ad-hoc process, several advantages are gained, but most notably, the ability to queue activities and have certain probes (e.g., CAP content detection) automatically run.

nsrmmgd

In the same way that nsrjobd sits between nsrd and savegrp operations, nsrmmgd sits between nsrd and nsrlcpd. The nsrmmgd daemon exists to manage jukebox operations. While nsrlcpd actually goes off to organise library operations, nsrmmgd is responsible for managing jukebox operation requests.

nsrindexd

On the server, you’ll typically find one nsrindexd process running per incoming backup, but there’ll always be one nsrindexd running. These processes are responsible for updating client file indices, and coordinating access to the indices for recoveries, etc.

nsrmmdbd

This is the media database daemon, and is responsible for coordinating updates to and record retrieval from the media database.