Storage Node Selection Across a WAN
Northwind Logistics runs NetWorker 19.8 with server nw-srv01 in Amsterdam, storage node sn-ams01 (LTO-9 library), and storage node sn-sin01 (60 TB AFTD) in Singapore. Singapore has 250 file clients; Amsterdam has 40 database clients. Singapore backups are missing the 9-hour window: job details show reads at 18 MB/s and data paths from Singapore clients to sn-ams01, although sn-sin01 has free capacity. Client resources were created from a template with the Storage Nodes field left empty. DNS uses short names plus search suffixes. A new Data Domain dd-sin01 is licensed for Client Direct, and 30 Singapore clients have Client Direct enabled, but their jobs still traverse sn-sin01. The firewall allows 7937-9936 between the server and storage nodes but blocks client-to-DD traffic.
1. Why are Singapore clients selecting sn-ams01, and how would you correct the selection for 250 clients without editing each GUI? Include the resource attribute and a safe bulk method.
Read the worked answer
The client resource's Storage Nodes attribute is empty. A client with no storage-node list does not automatically pick the nearest site; the server selects a storage node that can write the action's target pool, which can be the server or a remote storage node. For 250 clients, first confirm sn-sin01 has enabled devices in the target pool. Then set each client's Storage Nodes to sn-sin01. Use nsradmin in batch: export the client names, generate a script containing update type: NSR client; name: <client> and Storage Nodes: sn-sin01, and run nsradmin -i script. Test one client and verify the job details show the local data path. The storage-node field still matters for non-Client-Direct saves.
2. Client Direct is enabled on 30 clients but traffic still goes through sn-sin01. What conditions must be true for Client Direct, and what would you check first?
Read the worked answer
Client Direct requires all of the following: a DD Boost device configured with Client Direct and present in the selected pool; the client resource's Client Direct attribute enabled; network reachability and the required DD Boost ports from client to dd-sin01; valid DD Boost authentication; and a backup action that actually targets the DD pool. If any condition fails, NetWorker falls back to the storage node, which explains the traffic through sn-sin01. Check the action's pool first, then the device's Client Direct setting, then the firewall and DD Boost credentials. Also confirm the clients are not writing to an AFTD pool.
3. sn-sin01 fails at 22:00. What happens to the 250 clients, and what design would you recommend for fallback without recreating the WAN problem?
Read the worked answer
If each client's Storage Nodes list contains only sn-sin01, jobs wait or fail; NetWorker does not silently use sn-ams01. If sn-ams01 is listed second, failover crosses the WAN and will likely miss the window. Recommend a local primary plus a local secondary (a second AFTD or Client Direct to dd-sin01) rather than a remote storage node. Use clone or Data Domain replication for DR instead of WAN backups. Keep the remote storage node out of client lists unless an explicit emergency override is acceptable, and monitor for storage-node down events.