IBM Spectrum Protect Admin common mistakes
IBM Spectrum Protect Admin · Understand the traps and how to avoid them.
Edits an active copy group's version or retention parameters and assumes existing backup versions are immediately re-evaluated, without running VALIDATE POLICY and ACTIVATE POLICYSET.
Candidates conflate defining policy with activating it. Copy-group changes affect new backups and expire processing; the active policy set must be validated and activated, and existing file bindings age out under the new rules rather than being rewritten instantly.
What to do instead
Run VALIDATE POLICY domain setname, then ACTIVATE POLICYSET domain setname, and confirm with QUERY COPYGROUP. Explain to yourself which versions are governed by the old versus new rules and use EXPIRE INVENTORY to apply retention.
Confuses VEREXISTS, VERDELETED, RETAIN ONLY, and RETAIN EXTRA when predicting how many backup versions are retained for existing, deleted, and inactive files.
Candidates memorize default copy-group values without mapping each parameter to backup behavior. VEREXISTS limits versions for files that still exist, VERDELETED limits versions for deleted files, and RETAIN ONLY versus RETAIN EXTRA changes whether only the latest version or additional versions are kept.
What to do instead
Use QUERY COPYGROUP and build a small timeline: file backed up on days 1, 3, and 5, deleted on day 7. Apply each parameter to that timeline and state which versions expire and when.
Defines a primary storage pool but no NEXTSTPOOL destination, then expects automatic migration to move data when the high migration threshold is reached.
The high threshold triggers migration only when a next storage pool is configured and migration is enabled. Without NEXTSTPOOL, the pool fills and backups fail or stop, even though the threshold was crossed.
What to do instead
Set NEXTSTPOOL with UPDATE STGPOOL pool NEXTSTPOOL=nextpool, verify with QUERY STGPOOL, and confirm migration is enabled. Test with MIGRATE STGPOOL manually and watch QUERY STGPOOL percentages.
Creates a storage pool and device class but defines no volumes or scratch volumes, then expects client backups to succeed.
A device class describes device access; a storage pool needs volumes before data can be written. Candidates sometimes assume the server allocates space automatically or that labeling a library volume is enough without assigning it to the pool.
What to do instead
Define volumes for the pool or ensure sufficient scratch volumes exist in the device class. Label library volumes, check QUERY VOLUME and QUERY LIBVOLUME, and verify MAXSCRATCH is adequate for peak backups.
On AIX or Linux, edits dsm.opt for server connection settings instead of the dsm.sys server stanza, or sets SERVERNAME without a matching stanza.
The client reads server definitions from dsm.sys on these platforms; dsm.opt mainly points to the stanza via SERVERNAME. Candidates familiar with Windows dsm.opt editing apply the wrong file model and the client cannot find the server.
What to do instead
Edit dsm.sys with TCPSERVERADDRESS, TCPPORT, and the correct stanza name, set SERVERNAME in dsm.opt to that stanza, then verify with dsmc query session and review dsmerror.log.
Defines a client schedule and assumes the node will run it, without defining a schedule association or confirming that the client acceptor or scheduler service is running.
Schedules and associations are separate objects. A schedule does not target a node until an association exists, and the client must run the acceptor or scheduler service to receive and execute work.
What to do instead
Define the association with DEFINE ASSOCIATION STANDARD domain schedule node, verify with QUERY ASSOCIATION, start dsmcad or the scheduler service, and check QUERY EVENT plus the activity log for completion status.
Uses a client node ID and password to run administrative commands, or grants SYSTEM authority when only POLICY authority is needed for policy-domain work.
Node identities and administrator identities are separate. Candidates also over-grant authority because they do not map tasks to privilege classes, which violates least privilege and produces authorization failures or unsafe administration.
What to do instead
Register a separate administrator with REGISTER ADMIN, grant the minimum class such as POLICY or OPERATOR with GRANT AUTHORITY, and verify with QUERY ADMIN and QUERY AUTHORITY. Use the admin ID for administrative commands.
Assumes a restore can read only from the primary storage pool, and does not check copy-pool volumes, access mode, or offline volumes before concluding data is unrecoverable.
Restore processing can use copy-pool data when primary data is unavailable, but only if volumes are accessible and not set to unavailable. Candidates often stop at the first mount or access failure.
What to do instead
Check QUERY VOLUME for access=readwrite, readonly, or unavailable, bring copy-pool volumes online, and verify volume availability in the library. Retry the restore and inspect the activity log for mount or media errors.
Queries the activity log with a vague or default date range, or without BEGIN and END, then concludes that an event never occurred.
The activity log has limited retention and default queries may return only recent or limited records. Candidates also misuse date formats, so the query silently misses the relevant window.
What to do instead
Use QUERY ACTLOG BEGIN=date/time END=date/time with the correct server date format, or use FROMDATE/TODATE where supported. Check event retention with QUERY STATUS and enable event records with SET EVENTRETENTION if needed.
Installs the server with default database and recovery-log sizing and gives no thought to active-log mode or growth, then is surprised when the database or active log fills during backup or migration.
Candidates treat installation as a next-next-finish task and ignore capacity planning. The database, active log, and archive log have different growth patterns, and logmode affects recovery options.
What to do instead
Size the database and active log for the workload, choose logmode appropriately, add database and recovery-log volumes before production use, and monitor QUERY DB and QUERY LOG. Review growth after test backups and migration.