Dell NetWorker Deploy 2023 cheat sheet
Dell NetWorker Deploy 2023 · Keep the key ideas within reach.
NetWorker Architecture and Components
A NetWorker datazone consists of exactly one NetWorker server plus its clients, storage nodes, and devices; servers cannot share clients or devices across datazones.
The NetWorker server runs the nsrd daemon (job and resource database service) and nsrexecd; the RAP (resource allocation database) stores all configuration resources such as clients, pools, and policies.
nsrjobd schedules and launches jobs; nsrmmd is the media multiplexor daemon that writes data to and reads data from devices on behalf of a storage node.
A storage node is a host with devices attached; the server is always its own storage node, and remote storage nodes require the NetWorker client software plus the storage node component.
The client file index (CFI) tracks backed-up file paths for browsing and directed recovery; the media database (mm) tracks which save sets reside on which volumes.
Bootstrap save sets contain the server's RAP database, CFI, and media database and are required to rebuild a NetWorker server after loss.
The management console (NetWorker Management Console / gstd) provides the GUI and reporting; it is a separate installable component from the NetWorker server binaries.
Authentication uses the NetWorker auth service (nsrauth on port 9090 by default); the NetWorker Authentication Service (JBoss-based) handles AD/LDAP and local user authorities in modern releases.
A save set is the unit of backup for one client filesystem or database, identified by client name, save time, and level; a volume is the physical or logical media target (tape, AFT, or DD/Data Domain).
Installation and Initial Configuration
NetWorker server installation requires a license (traditional or capacity/CLP-based); the evaluation period is limited, so confirm entitlement before production use.
The NetWorker Authentication Service must be configured during or immediately after install; the default admin account (administrator) is created there, not in the RAP database alone.
The NetWorker Management Console (NMC) server can be installed on the NetWorker server or a separate host; the NMC server requires its own database (embedded or external) and a gstd service.
On Linux, RPM-based installs use the lgtoman/nsr packages; on Windows, the installer registers services nsrd, nsrexecd, and (if chosen) gstd.
The server hostname must resolve consistently forward and reverse on all datazone hosts; mismatched short/long names cause authentication and client registration failures.
Configure the server's devices and a default pool before creating clients, because client backup actions require a target pool with eligible volumes.
The NetWorker server's own client resource is created automatically; add the server to a backup group and schedule so bootstrap and index backups occur.
After install, verify services with nsrwatch or the NMC, and confirm the auth service is reachable on port 9090; test with a manual save of a small directory.
Client Configuration and Backup Policies
A policy contains workflows; a workflow contains one or more action groups; a group binds clients to a workflow and defines the start time and snapshot/backup options.
Backup levels follow the classic scheme: full, incremental (changed since last backup of any level), and level-based (1-9, changed since last backup of a lower level); log-based and synthetic levels also exist.
A schedule resource defines which level runs on which day; the schedule is attached to the action/protection group, not to the client directly.
The client resource holds the save set list (e.g., /home, ALL, or system-specific paths), the backup command, and the remote access and remote user fields for recovery permissions.
Directive resources (e.g., skip, compress, index, asm) control what is backed up and how; directives are applied per client and can be nested.
Retention is set by the pool's retention period or by the client's browse and retention policies; browse time must be less than or equal to retention time.
The client's save set for a Windows host typically includes drives (C:, D:) and system state via the ALL or specific save set entries; VSS is used for open-file consistency.
A client can belong to only one group per workflow path; overlapping schedules for the same save set cause duplicate or conflicting backups.
Scheduled backups require the client's nsrexecd service running and the server's authentication to succeed; manual saves use save -c client -l level.
Recovery and Cloning Operations
Recovery types: file-level (browse the CFI and recover selected files), save set recovery (recover an entire save set including its index), and directed recovery (recover to a different client).
The recover command uses -c client, -s server, and -d destination; the client file index must be present for browsing, otherwise use save set recovery.
A clone operation copies save sets from a source volume to a clone volume, typically to a different pool (e.g., a long-term or offsite pool).
Cloning requires a clone pool with eligible volumes and a clone resource (or the NMC clone action); the clone copy is tracked in the media database as a clone instance.
Synthetic full backups are created by cloning and merging incremental save sets into a full, reducing the number of save sets needed for recovery.
A bootstrap recovery rebuilds the NetWorker server from the bootstrap save set; it requires the most recent bootstrap and the server binaries.
Recovery of a client requires the client's nsrexecd and the appropriate remote user/remote access permissions on the client resource.
The recover program can restore to the original location or an alternate path; use -R for alternate recovery path and -i for interactive browsing.
Monitoring, Reporting, and Troubleshooting
The daemon.raw log on the server records server activity; use nsr_render_log to convert it to readable text, and check daemon.raw for job failures and authentication errors.
nsrwatch shows active jobs and daemons; the NMC's Monitoring tab shows job status, alerts, and device status.
The media database (mminfo) reports save sets and volumes; mminfo -avot lists all volumes, and mminfo -q 'client=host' filters by client.
The client file index can be queried with nsrinfo; use nsrinfo -n all -s server client to list indexed save sets.
Common failure causes: name resolution (forward/reverse mismatch), expired credentials in the auth service, full or offline devices, and client nsrexecd not running.
The NMC reporting feature provides backup and recovery reports; reports require the NMC server's database and the datazone's server to be reachable.
Job status in the NMC shows 'Succeeded', 'Failed', or 'Interrupted'; interrupted jobs often indicate a lost connection to the client or storage node.
Check the client's own daemon.raw and the server's daemon.raw together; the server log shows the job launch, and the client log shows the save command execution.
Security, Authentication, and Access Control
NetWorker uses the NetWorker Authentication Service for user authentication; local users and external authorities (AD/LDAP) are configured there, and the NMC uses the same authority.
User groups in the RAP database grant privileges; the 'Administrators' group has full access, and other groups can be limited to specific operations and datazones.
The client resource's 'Remote Access' and 'Remote User' fields control which users and hosts can recover data from that client.
The server's auth service uses TLS; certificates are stored in the NetWorker auth keystore, and expired or mismatched certificates cause login failures.
Role-based access in the NMC maps users to roles such as Console Administrator, Console User, and Security Administrator; these roles are separate from RAP user groups.
The NetWorker server's 'NSR peer information' resource stores the host certificates used to authenticate clients and storage nodes; stale peer info causes authentication errors.
Audit logging records administrative actions; enable it to track changes to policies, clients, and devices for compliance.
Access to devices and volumes is restricted by the storage node's device access and by the server's user group privileges; a user without the required group cannot label or mount volumes.