Not sure if this is a duplicate post...tried earlier but it disappeared.
I need to duplicate to tape images that are under an SLP that failed. Fits the situation in TECH60675, nothing in the output of nbstlutil, but any attempt to manually duplicate gets the message "it is a lifecycle image that cannot be manually duplicated"
Tech60675 says "the NetBackup administrator has the ability via the Command Line Interface to release the lock on the image by changing the state to "Lifecycle Complete" in the catalog. The Catalog functions can now be used to run the duplications manually to the other storage destinations.", but it does not say how. I looked at bpimage and bpstlutil, including any hidden options.
This is NetBackup 6.5.6 on Solaris.
Anyone know how to change the image state to 'LifeCycle Complete' (state 3)?
Solved! Go to Solution.
A "state 3" means COMPLETE, so SLP is not going to process the image anymore.
You can do it by: nbstlutil cancel -backupid <backupID>
This is like taking the image out of SLP operation then you can proceed with your manaul duplicaton of the image.
These images are not known to 'nbstlutil', if you try to list them they are not there. I tried what you suggested, it gives no error but if I use bpimagelist -L it still shows 'STL_Completed: 1' and it still refuses to manually duplicate the images.
Interestingly bpimagelist -stl_incomplete does not list these images, but I still cannot manually duplicate them. The only thing that seems to work is to use bpimage -recalculate to set the expiration to someting less than 'infinite', but I have not found a way to make a copy so that I can free up the disk space they take.
It seems to relate to the different EMM tables used but I need a way to set that 'STL_Completed' field.
Have these images been processed by SLP before? If it can't be checked by nbstlutil, I doubt it's not a SLP image. If it was, surely some inconsistency exists in the EMM database, might need to log a support call.
I agree with Yasuhisa - PLEASE upgrade!
TECH60675 is a Bug Report for 6.5.x and says that a fix will be included in a 'future release'. It does not say which future release.
LOTS of SLP fixes and enhancements have been included in 7.1 and 7.5.
NBU 6.x has reached EOSL in Oct last year.
I suspect there is a mis-match somewhere in the image, image copy and/or image fragment tables in the database.
TBH, only way to resolve this is via a support call.
If it fails to duplicate, and you have already run nbstlutil cancel -backupid <backupid> then there are not any commands left.
Log a call, send in
nbdb_unload <some dir> (dir will be auto created)
nbdb_backup -online <someother dir> (need to create the dir first)
nbsu -c -t output
A very clear description of theissue, including an example of the commands run.
You may have edited your SLP at some point and so your image relates to an earlier version of the SLP itself
First do a nbstlutil list -backupid ***
against one of your backups - see what version it says it relates to ... then try the cancel -backupid with the -version x switch
We've not got the bottom of why we get images in this state but the incidence is much less than it was. We think it arose from a combination of failed FT transport backups, using "nbstlutil cancel" and zombie bptm processes being forceably killed. There no longer seem to regularly be images in this state so when everything else works the disk pools do eventually empty after a few days.
In summary we can live with this issue now the we are aware that it can happen, and that leaves us free to concentrate on other interesting features of SLPs.