NBU 6.5.6: SLP duplication failed with exit code 190

[Attax]

Hi all,

i've a problem with Storage lifecycle Policy.

The master server is a w2k3 machine with nbu 6.5.6; i have some different Slp, configured like this:

1st step: backup on disk by the master server (expire after duplication)

2nd step: duplication on tld0 by the master server (different retention based on SLP; example 1month)

3rd step: duplication on tld1 by the master server (different retention based on SLP; example 1month)

The problem is that sometimes i get duplication job in the activity monitor that instantly fails with error 190.

According to me, the problem is that the SLP process references some backup that no longer exist in catalog; if i run the command "nbstlutil stlilist" it shows me some backupid that have already expired.

i.e.:

C:\>nbstlutil stlilist

V6.5 I l862hl02_1281286887 SLP_3months_2copy 3

V6.5 I grpi-ora-pv03_1284656505 SLP_3months_2copy 3

[omitted]

as you can see, these backup were written in September (1284656505 = Thu Sep 16 19:01:45 2010) and now are expired from the image catalog.

I've tried to "nbstlutil cancel" and "inactive" those queued jobs, but it simply does nothing: it gives no error, but the lifecycle is always there.

How can i delete those jobs?

P.S.: sorry for my bad english!

Thanks in advance

Andrea

[Marianne]

Ensure that the tld0 copy is the source for the tld1 copy.

Extract from SLP overview:

Hierarchical duplication is simple to configure using the storage lifecycle policy GUI. The various storage destinations are configured in the usual way and can then be arranged in a parent/child relationship using the four arrows shown in Figure below. The indentation of the storage destinations in the "Use for‟ column of the GUI indicates the relationship between them with the more indented destination duplicating from the less indented destination immediately above it.

[Attax]

Hi Marianne,

thank you for your response, but my question was different. What i want is to delete the jobs that i see with the command "nbstlutil stlilist" , because some of them are old entry of backup that are already expired.

Thank you,

Andrea

[Marianne]

SLP images will actually only expire once the duplication has succeeded.

Do these duplications actually show up as Incomplete?
nbstlutil stlilist -image_incomplete -U
 

nbstlutil cancel will only work if jobs are listed as Incomplete.

[Attax]

I know about that, but i think that the customer expired manually the backup with "inifinity" retention; actually those backup are listed as complete. I can't do the command you listed right now, but i'm sure about that.

By the way, i always thinked that complete jobs aren't listed with "nbstlutil stlilist" command, indeed i can see only 2 or 3 jobs "completed but not deleted" from the list.

Hope to have been clear

[Attax]

No one that has seen this issue?

Andrea

[trectenw]

I am having this same issue.  In my environment we have long since gotten rid of the storage lifecycle policies.  However, when I run:

nbstlutil list

I see a lot of entries referring to policies that have been deleted.  When I attempt to do an "nbustlutil cancel..." on any of them, I get no return and they do not get removed.  When I run "nbstlutil stlilist -image_incomplete -U" nothing returns  If I run a "bpexpdate -d 0 -backupid <backup_id>" on them it says that the entity doesn't exist.

Seems like they are just stuck there forever.  Any help would be appreciated.

[watsons · Accepted solution]

Since the image was expired manually with bpexpdate, I believe you don't care about having that image back anymore.. is it?

So now we know image database does not have that image anymore. But it appears in your "nbstlutil stlilist" that means it's still in EMM database. If "nbstlutil cancel" cannot remove it, then the best probably is to call Support and have them create SQL script for you to clean up that image entry in EMM.

You will need to prepare to run nbdb_unload, which is to dump the database for Support to check.