06-04-2015 05:04 AM
Hi,
Our SLPs for weekly and monthly backups are staged first to local Data Domain, then remote Data Domain then finally to tape. As we only have two active tape drives at the busiest times we have a backlog of writes to tape of several days.
One backup from Mon night has not written to tape and the command nbstlutil stlilist -image_incomplete -U to view queued SLPs doesn't show it. I can manually duplicate it from the catalog. But I'm baffled as to why it has never run or even tried to run.
On Tues I modified the SLPs it used, as the Monday night job was a custom emergency backup and I've changed the SLPs since, taking the tape write off the "Daily_Full" application schedule. Could changing the SLP after the job originally ran prevent the desired write to tape from running?
Thanks
Solved! Go to Solution.
06-04-2015 07:43 AM
No, when you modiffy an SLP it creates a new version that becomes the 'active one'.
Jobs already run but not duplicated will keep the previous 'settings' and complate using those.
Some settings, can be changed on the fly, and will affect not yet completed jobs.
The TN I posted below shows what can be changed and what can't.
It is TN HOWTO34796 - it was unplublished, so internale only hence the copy/ paste, I've republished it but it's not live (yet) for some reason.
Its concerning if an SLP went complete without duplicating - in fact that is quite concerning as the whole idea of SLP is that it doesn't do that. Is it possible it was cancelled by accident, as that is the only thing I can think of.
06-04-2015 07:40 AM
Administrators can make changes to a storage lifecycle policy in one of the following ways:
Using the NetBackup Administration Console or bpadm command.
Any change that an administrator makes to a storage lifecycle policy using the NetBackup Administration Console or bpadm creates a new storage lifecycle policy version. The new version is created when the changes to the storage lifecycle policy are committed or saved. The NetBackup Administration Console and bpadm always display the most recent version.
If an administrator uses nbstl to make a change to a storage lifecycle policy, nbstl creates a new version by default.
However, the nbstl command contains options to view different versions and to modify the definitions of existing storage lifecycle policy versions without creating a new version. The options are as follows:
Use -modify_current or -modify_version to change any of the following configuration options:
Some fields require values for all of the destinations in the storage lifecycle policy. Make sure that the number of values that are specified for the fields matches the existing destination count.
For example, in a storage lifecycle policy that contains three destinations, to change the value of one, a value must be given for all three destinations. Note that the values for all three destinations are replaced. To change the value for the second destination, provide the existing values for the first and the third destinations.
Some configuration options cannot be changed using -modify_current or -modify_version. To change any of the following options, you must create an entirely new storage lifecycle policy version:
06-04-2015 07:43 AM
No, when you modiffy an SLP it creates a new version that becomes the 'active one'.
Jobs already run but not duplicated will keep the previous 'settings' and complate using those.
Some settings, can be changed on the fly, and will affect not yet completed jobs.
The TN I posted below shows what can be changed and what can't.
It is TN HOWTO34796 - it was unplublished, so internale only hence the copy/ paste, I've republished it but it's not live (yet) for some reason.
Its concerning if an SLP went complete without duplicating - in fact that is quite concerning as the whole idea of SLP is that it doesn't do that. Is it possible it was cancelled by accident, as that is the only thing I can think of.
06-04-2015 07:43 AM
Depends upon how you modified an SLP.
The first thing o be aware of is that the GUI only shows you the latest/current version of an SLP.
If you modify an SLP in the GUI, then this only shows you the new modified version.
If you modify an SLP in the GUI which has pending/incomplete/suspended/paused work, then the original SLP is retained with an earlier version number.
The only way to amend an SLP of an earlier version (i.e. one with pending incomplete work) is to use the CLI.
Any prior (non-current) versions of SLPs are removed if and when all of their work is complete, and/or there is no work to be done - i.e. if you modify an SLP twice and both of these current (at the time) SLPs were not called upon to do work, then the prior versions are removed too.
.
So, if you modify an 'earlier' version of an SLP, which still had work to do, or your change/modify/delete the 'storage units' that the prior versions of SLPs are still relying on, then yes - it is possible to cause SLPs to fail forever - until you either resolve the storage unit issues or cancel the pending SLP workloads.
Have a look in the CLI manual for commands which will list 'versions' of SLPs, and then use those 'versions' in second list commands to list the work outstanding/incomplete for the 'prior' versions. i.e. the presence of a prior version SLP indicates pending work to be completed.
06-05-2015 12:17 PM
06-05-2015 12:33 PM
Nice post sdo - yes, in theory changes could cause an SLP to fail, but it shouldn't go to a completed state without duplicating - it would (or should) just stay at 'infinity' forever ...
06-05-2015 01:34 PM
Also, if you edit a suspended SLP with the GUI and then unsuspend it, you're unsuspending the new version, not the old version. Only the CLI can unsuspend a previous version of an edited SLP.
06-05-2015 11:39 PM
Ok, got the link working now for the TN I mentioned previously:
http://www.symantec.com/docs/HOWTO34796