Staggering 1,200 Client Schedules and Admin Jobs
A Spectrum Protect domain serves 1,200 nodes through one server. The backup window is 20:00 to 02:00. All nodes are associated with one client schedule that starts at 20:00, has duration 6 hours, and uses client option RANDOMIZE=25. The server MAXSESSIONS is 80, and the tape library has 20 drives. Admin schedules run migration at 23:00, expiration at 01:00, and reclamation at 02:00. Event reports show 140 nodes marked Missed each night, backups still running at 03:30, and expiration sometimes waiting on tapes. The help desk also reports that a node moved to a new subnet has not backed up for five days, although manual dsmc works. The operations team wants to add more drives, but the budget is tight.
1. Analyze the scheduling problem and recommend a staggered schedule design. Include the roles of MAXSESSIONS, randomization, and admin job placement.
Read the worked answer
The single 20:00 schedule with RANDOMIZE=25 spreads start times over only 90 minutes. With 1,200 nodes, MAXSESSIONS=80, and 20 drives, the server cannot start all nodes immediately; nodes that cannot start within the 6-hour duration are marked missed. Estimate: if a node needs 20 to 30 minutes, 1,200 nodes at 80 concurrent sessions is 15 waves, or 5 to 7.5 hours, already beyond the window. Adding drives helps only if tape, not session slots, is the bottleneck. I would split nodes into three or four schedules by business unit, starting at 20:00, 21:00, 22:00, and 23:00, keep randomization modest, and set per-node RESOURCEUTILIZATION so one node cannot take many sessions. Move migration to after 02:00, expiration after migration, and reclamation outside the backup window. Raise MAXSESSIONS only after checking CPU, DB, and drive utilization.
2. Manual dsmc works for the node on the new subnet, but scheduled backups do not. Explain the likely cause and what to check.
Read the worked answer
Manual dsmc works because the client initiates an outbound connection to the server. Scheduled backups may be prompted, where the server initiates a connection back to the client, so a new subnet and firewall can block the server-to-client path while outbound client traffic still works. Check the server SCHEDMODE, QUERY SCHEDULE for the node, the client scheduler log, and whether the client acceptor is running and registered on the correct port. Also check that the node's TCP address and port were updated and that the schedule association was not lost. If prompted mode cannot be opened, switch that node group to polling mode so the client contacts the server, or open the required acceptor port. Confirm the fix with a scheduled test, not only a manual backup.
3. Design event logging and automation to catch missed backups earlier. What queries and reports would you use?
Read the worked answer
Use QUERY EVENT with a begin date and filter for STATUS=Missed or Failed; review it daily. Set EVENTRETENTION long enough to cover a weekly trend. Report on nodes with no successful backup in 24 hours, not just schedule failures, because a node can be associated but disabled. Pair event reporting with QUERY SCHEDULE and client-side logs. For automation, run a daily admin schedule that writes the exception report and alerts the service desk; do not auto-delete or re-run everything without checking why the node missed. Keep an audit trail of schedule changes. If the report shows repeated missed schedules, compare start-time distribution, session limits, and tape mounts before adding hardware.