Dell NetWorker Deploy 2023 common mistakes
Dell NetWorker Deploy 2023 · Understand the traps and how to avoid them.
Treating the NetWorker server, storage node, and client as one co-located install and assuming every backup path flows through the server, so questions about data movement and licensing are answered with the wrong component.
Lab setups and small deployments often collapse all three roles onto one host, so candidates never see the separation between control-path (server) and data-path (storage node to device) traffic. Exam items that describe a remote storage node or a SAN environment then get answered as if the server always moved the data.
What to do instead
Before answering architecture items, sketch the three roles and mark which one owns each artifact: the server owns the client resource, media database, resource database, and job scheduling; the storage node owns the device and moves data; the client owns the save sets it sends. Then ask which host the described data path actually touches.
Confusing the media database with the resource database when asked where backup metadata or configuration lives, and expecting either one to be a simple flat file that can be edited by hand.
Both are internal NetWorker databases and both are backed up by the bootstrap, so candidates lump them together. The distinction (tracking save sets and volumes versus storing client, policy, device, and schedule configuration) is rarely exercised in day-to-day use.
What to do instead
Memorize the split: media database = what was backed up, to which volume, when; resource database = how the server is configured (clients, policies, devices, pools). Both are captured in the bootstrap save set, which is why bootstrap protection is a recurring exam theme.
Planning an installation without checking the required order of operations, then answering questions as if clients can be configured before the server's devices, pools, and policies exist.
Candidates memorize individual screens rather than the dependency chain, so they place client creation, pool creation, and device configuration in arbitrary order.
What to do instead
Learn the chain: install and license the server, configure devices and label volumes, define media pools, build policies/workflows/action groups, then create client resources and assign them to groups. Any exam scenario asking 'what must be done first' is testing this chain.
Ignoring how the server's hostname, IP, and name resolution are fixed at install time, and assuming they can be changed later without consequence.
Candidates treat the hostname as cosmetic. In practice the server's identity is bound into its configuration and into client resources, so later renames break communication and licensing.
What to do instead
Treat the fully qualified server name and stable IP as install-time decisions. For exam items about connectivity failures after a rename or IP change, look for name-resolution mismatch and client resource hostname mismatch as the root cause before suspecting the daemons.
Answering client configuration questions without distinguishing the client resource's save set list, the schedule, and the group membership, and assuming one setting controls what gets backed up and when.
The client resource is a single form with several independent fields, and candidates conflate 'what to back up' (save sets and directives) with 'when to back up' (schedule via the action/workflow) and 'which job includes it' (group membership).
What to do instead
For each scenario, name which field answers the question: save sets and directives control content; the schedule and workflow control timing and retention; group membership controls which workflow picks the client up. If a client is never backed up, check group membership first, then the workflow's schedule window.
Assuming a backup that finished 'successful' means every file was captured, without checking for skipped files, directive-based exclusions, or save set failures inside the job.
Job status is reported at the workflow/action level, so partial failures inside a client's save set can be masked by an overall completion status. Candidates who only read the top-level status miss this.
What to do instead
When a question mentions missing data despite a green job, check the save set detail for failed or skipped files, verify directives are not excluding the path, and confirm the client's save set list actually includes it. Also confirm the volume had space and the pool accepted the save set.
Configuring a storage node or device without verifying that the device is visible and accessible to the storage node host, and expecting the server to be able to use any device it can see.
Device configuration is often taught from the server's UI, which hides the fact that the storage node host must own and access the device. Candidates answer as if device visibility on the server is sufficient.
What to do instead
For any device or storage node scenario, verify in order: the device is presented to the storage node host, the storage node resource exists and the device is assigned to it, the device is enabled and labeled, and the volume is in a pool the workflow can write to. Device-not-ready and volume-not-in-pool errors point to different steps in that chain.
Treating cloning as a backup and assuming clones satisfy the same retention and recovery requirements as the original save sets, or assuming a clone can be used without the original media database entry.
Cloning copies save sets to another pool but does not create an independent catalog entry that survives loss of the server's media database unless the bootstrap is also protected. Candidates answer recovery questions as if the clone alone is sufficient.
What to do instead
Remember that clones are tracked in the same media database and recovery from a clone still requires a valid server catalog. Pair cloning with bootstrap backup and, for offsite copies, verify the clone pool retention covers the required recovery window.
Answering recovery questions with the wrong recovery type, using a save set recover where a directed recover or a full server disaster recovery is required, or vice versa.
The recovery options look similar in the interface and the names are close, so candidates pick the one they used most recently rather than matching the scope of loss described in the scenario.
What to do instead
Map the loss to the tool: individual files from a known save set = save set recover; files to a different host or path = directed recover; lost client system volume = client file index plus bootstrap-assisted recovery; lost server = bootstrap and resource database recovery first, then client data. Identify the scope before choosing the command.
Diagnosing access or authentication failures by resetting passwords or reinstalling, instead of checking the NetWorker user group membership, the client's remote access list, and the authentication authority in use.
NetWorker authorization is layered: OS-level or external authentication establishes identity, then NetWorker group membership grants role, and per-client remote access controls who may back up or recover that client. Candidates collapse these into one 'permissions' concept.
What to do instead
For access failures, check in order: is the user authenticated by the configured authority; is the user a member of the appropriate NetWorker administrators/user group; and does the client resource's remote access list include the host performing the operation. Address each layer separately rather than resetting credentials.