Nomenclature

7In 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.

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.

nsrexecd

The client process. You’ll find this running on all hosts in the datazone, regardless of whether they’re servers, storage nodes or clients. Most NetWorker processes, including the server (nsrd) process itself, are dependent on nsrexecd running.

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.

gstd

The gstd process is the NetWorker Management Console server daemon. You’ll find this running on whatever machine the NetWorker Management Console server has been installed on. For small sites, this is likely to be the NetWorker server itself; for larger environments it is reasonably common to see a separate server setup for handling incoming NMC connections.

dbsrv9

This is the Sybase iAnywhere database server process that runs on the NetWorker Management Console server to handle storage and retrieval of all long-term information for reports and other historical information within NMC.

Commands

What’s the difference between a command and a process/daemon? A process/daemon is a common that (depending on the host) you should reasonably expect to see running all the time. For instance, on the NetWorker server itself, NetWorker won’t operate unless the core daemons (nsrd, nsrexecd, nsrindexd and nsrmmdbd) are running. They have to remain running at all times.

Commands, on the other hand, are intermittent processes that are executed either by NetWorker or the user to perform a specific, individual function.

nsrmm

The nsrmm process serves two different functions; the first is that it interacts with the media database for a variety of functions including setting/clearing volume flags (e.g., full, recyclable), setting and clearing saveset flags (e.g., suspect, notsuspect, recyclable, etc.), and allowing manual intervention on retention periods.

If you’re working in an autochanger environment, you may not be aware of it but nsrmm can also be used for device/volume manipulation; e.g., mounting a volume in a standalone tape device (or ADV_FILE type device), dismounting, labelling, etc. (This can sometimes be handy in a jukebox environment, but should be used with caution there.)

nsrjb

The nsrjb command is used to control and interact with jukeboxes. With it you can load and unload volumes, label volumes, withdraw/deposit media, check on the status of the jukebox and issue reset commands. If you’re working with autochangers/jukeboxes, it’s one of those commands that you’ll get to know with great intimacy.

With the exception of status commands, you should also always run it with “-vvv” arguments on the command line. This will show you more clearly what NetWorker is up to in each stage of communication with the jukebox.

save

This is the base filesystem backup tool. When NetWorker does an automated backup, nsrjobd will run the appropriate group, which in turn will connect to the appropriate client with a save command for it to run. The client will run that command and the data will be sent to the appropriate nsrmmd process (with meta-data returning to the NetWorker server). Alternatively, if you’re wanting to run a manual backup from the command line of a file or files, you’ll be using save.

savepnpc

This is “save with pre and post processing”; it’s a special version of the save command, typically invoked only by the NetWorker server as part of an automated backup. Instead of just doing a standard filesystem backup, “savepnpc” will work with NetWorker to (optionally) perform additional, user-specified processing prior to backup starting, and after all backups have finished for the client. This can be used for something as simple as coordinating cold backups – but in reality, the sky is the limit when using savepnpc.

…more to come!