Rename Storage Lifecycle Policy?
Updated: 21 May 2010 | 9 comments
Hi,
Is there a commandline command that renames a Storage Lifecycle Policy?
Apparently you can't rename/copy a SLP using the GUI, but is it at all possible using the commandline?
Thanks!
Fred
discussion Filed Under:
Comments
Only commands I'm aware of are:
nbstl - add, delete, modify, or list NetBackup storage lifecycle policies (no options for renaming nor copying)
nbstlutil - run the NetBackup storage lifecycle policies utility which "provides a way for users to intervene in storage lifecycle operations" (so not a configuration command!)
Was going to say there was something in the Ideas section about this, but you've already been there!
https://www-secure.symantec.com/connect/idea/option-renaming-policy
Regards Andy
"It's not too late to panic ..."
yes, everybody vote :)
Indeed,
Not being able to copy/rename slp or policies from the GUI is one of my pet peeves...
Everybody vote ;)
https://www-secure.symantec.com/connect/idea/option-renaming-policy
You can "cheat"
but I have absolutely no idea if this will have an adverse effect on the running of your NetBackup environment.
We don't actually use SLPs so I created one & then searched for any file of that name. Could only find one such entry & that was in /usr/openv/netbackup/db/ss, which was a simple file with the basic SLP entries. I copied this file via the OS & refreshed the SLP 'page' in the GUI - new copied file was present. Added this SLP to an existing test policy & then renamed it in the OS. The SLP was renamed in the SLP 'page' in the GUI but the entry in the policy for "Policy storage unit / lifecycle policy" was changed to "Any Available".
So maybe you can change it, but ....
I'm now going to sit & wait, watching to see if I've just broken ours!!
Regards Andy
"It's not too late to panic ..."
Do not rename.
The Best Practices for using Storage Lifecyle Polices in Netbackup say on page 13 "Do not edit an active SLP with in -process images.
From the document:
Do not edit a Storage Lifecycle Policy while it has images that are in process.
If a destination is deleted, images could be lost prematurely.
If you remove a storage unit from the NetBackup configuration and from the SLP while SLP images are in process, duplication for the images created prior to the change will not work. The SLP still wants to use the old storage unit for those images, but the storage unit does not exist. You could end up with an unmanageable backlog.
Seems there a good reason not to have the re-name option ;-)
Assumption is the mother of all mess ups.
If this post solved you’re questions please send a gratitude by marking it as a solution.
Renaming on the filesystem
Renaming on the filesystem is no doubt not supported, but probably does work...
Indeed you should first make sure no duplications are still pending...
Simple fact is it should be in the GUI ;)
The GUI Rename option should indeed either verify that there are no pending duplications (Or simply handle this appropriately)
Agree with you
But I guess that part of the codes wasn't ready when releasing. Thus no "rename" option.
Maybe CRZ can comment ?
Assumption is the mother of all mess ups.
If this post solved you’re questions please send a gratitude by marking it as a solution.
Oh no, my name has been invoked :)
I think it has something to do with our lack of "versioning" for SLP - which is to say, if you make a change, we would lose the data dealing with your policy from before you make that change, so you couldn't go back later and look at or use the stuff under the "old" policy because NetBackup doesn't remember it ever existed.
I know there were some improvements scheduled (for 6.5.5?) but I honestly don't remember what they are of if they're relevant to you. I guess we'll know in about a month when we all get 6.5.5. :)
We DID and DO have a lot of Tech Alerts about SLP, though, and I believe at least one of them cautioned against making changes while images were "in process" - let me see if I can find that one...
DOCUMENTATION: Unexpected results, up to and including data loss, may occur if changes are made to active Storage Lifecycle Policies (SLP).
http://support.veritas.com/docs/323746
(Fixes in 6.5.5)
TECH ALERT: Images written as part of a Storage Lifecycle Policy (SLP) may be prematurely marked as "lifecycle complete" prior to scheduled duplication due to a problem allocating resources from the operating system. This may lead to data loss when these images expire, having not been duplicated.
http://support.veritas.com/docs/324189
(Fixes in 6.5.4 and 6.5.5)
A potential for data loss has been discovered in NetBackup 6.5 / 6.5.x when using Storage LifeCycle Policies (SLP). Duplication jobs to disk that fail after writing one or more fragments may not retry for as long as expected.
http://support.veritas.com/docs/324515
(Fixes in 6.5.5)
I guess there's a LOT in 6.5.5, actually. :) Hope this helps!
Never said it was a good idea! :D
Still, wonder if it's 'workable' with no active jobs?
Not a big fan of manually mangling things (unless it's supported, obviously! ;) )
Regards Andy
"It's not too late to panic ..."
Hazards of a "rename"
When storage lifecyscles are in progress (just after the backup completes), Netbackup stores the information about these lifecycles in 3 separate tables in the EMM database.
EMM_Image - the information about the image, including: BackupID, Client name, Policy and lifecycle name (as a string, not a reference number, so a rename would break the link)
EMM_ImageCopy - information about each copy done, keyed to the BackupID
EMM_ImageFragment - information about the location of the fragment, keyed to the copy number and BackupID.
You can obtain the information from these tables using the "nbstlutil list -U" command.
I'm unsure as to the imact of changing the name of the storage lifecycle at the OS level if no lifecycles are currently progress. (ie: if "nbstlutil list" returns no records at all)
I'm almost certain of issues if you did so while lifecycles were still in operation.
Either way, I still do not recomend performing the rename in this way.
Sorry,
Luc.
Would you like to reply?
Login or Register to post your comment.