cancel
Showing results for 
Search instead for 
Did you mean: 

SLP replication - do queued SLPs fail if the original SLP is modified after the backup?

Steve_Law
Level 4

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

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

mph999
Level 6
Employee Accredited

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.

View solution in original post

7 REPLIES 7

mph999
Level 6
Employee Accredited

Storage lifecycle changes and versioning on Windows

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.

  • Using the nbstl command.

    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:

-all_versions

Use to display all versions of a storage lifecycle policy definition. Without specifying this option, only the most recent version is displayed by default.

-version number

Use to display a specific version.

-modify_current

Use with most nbstl configuration options to make changes to the current storage lifecycle policy version without creating a new version. Knowing the current version number is not necessary if this option is used.

-modify_version -version number

Use with most nbstl configuration options to make changes to a specific version without creating a new version.

Use -modify_current or -modify_version to change any of the following configuration options:

-dp

The duplication priority

-residence

The storage unit to be used for each destination

-pool

The volume pool for each destination

-server_group

The server group for each destination

-rl

The retention level for each destination

-as

The alternate read server for each destination

-mpx

The preserve multiplexing option for duplication copies

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:

-uf

The type of the destination: Backup, duplication, snapshot

-managed

The retention type for the destination: Fixed, capacity managed, expire after duplication

-source

The source of a destination, used primarily in hierarchical storage lifecycle policy configurations

-dc

The data classification of an existing version

 

The number of destinations. You cannot add a destination or remove a destination from the storage lifecycle policy definitions.

mph999
Level 6
Employee Accredited

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.

sdo
Moderator
Moderator
Partner    VIP    Certified

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.

Amol_Nair
Level 6
Employee
If you are aware of the backupid then could you post the output of the below 2 commands bpimagelist -backupid <> -L nbstlutil list -backupid <> -U

mph999
Level 6
Employee Accredited

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 ...

 

D_Flood
Level 6

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.

 

mph999
Level 6
Employee Accredited

Ok, got the link working now for the TN I mentioned previously:

http://www.symantec.com/docs/HOWTO34796