cancel
Showing results for 
Search instead for 
Did you mean: 

Old SLP images are not completed

Trf1-BRA
Level 4

Hi folks,

We are passing by this situation:

A lot of SLPs with 7 days retention to disk as primary copy and bigger retentions to tapes.
The problem is that before the second copy has ben completed the tape library has gone to a failure state.

So, now we have a lot of disk SLPs listed as expired date and we don't get to duplicate it to another STU or change the expire date, because the images referenced are part of a SLP.

Anybody has a suggestion to solve this situation? We wanna to mantain this backups at least at tapes.

 

Thanks,
Marcio Oliveira

10 REPLIES 10

mph999
Level 6
Employee Accredited

You should be able to modify the version of the SLP the imaages are using, and change the destination STU to 'something else'.

https://www.veritas.com/support/en_US/article.100007040.html

I'm presuming here that you haven't been able to fix the library, if that becomes available again the SLP should continue.  bpimaglist output should show which version of the SLP the image is using.

Failing abovr, providing the 1st copy of the SLP is NOT using 'expire after copy' you could use the no expire touch file, then cancel the image and extend the expiry using the bpexpdate -extend_expired option.  I would very highly suggest contacing support if you decide to do this.

Hi mph999, thanks about your answer.

The question is just because our library is working again, but old SLPs don't back to start automatically.

I'll try like you suggested and soon post here the tests.

 

Gratefully,

Marcio Oliveira

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Did you by any chance modify the SLPs while the library was broken? And then changed it back when the library was fixed?
Or perhaps deactivated the SLPs? 

Hi Marianne,

We have a very big netbackup enviroment and sometimes difficult to manage it, so when the library was broken, the SLPs kept itself activated. We made some changes (Priority), take a look:

C:\Windows\system32>nbstl Mensal -all_versions -L
                                Name: Mensal
                 Data Classification: Platinum
            Duplication Job Priority: 200
                               State: active
                             Version: 9
 Operation  1                Use for: 0 (backup)
                             Storage: dedup.stu.srvXXXx-xx
                         Volume Pool: (none specified)
                        Server Group: (none specified)
                      Retention Type: 2 (Expire After Copy)
                     Retention Level: 9 (infinity)
               Alternate Read Server: (none specified)
               Preserve Multiplexing: false
      Enable Automatic Remote Import: false
                               State: active
                              Source: 0 (client)
                        Operation ID: (none specified)
                     Operation Index: 1
                         Window Name: --
                 Window Close Option: --
                Deferred Duplication: no
 Operation  2                Use for: 1 (duplication)
                             Storage: TandBerg
                         Volume Pool: JFXX-Mensal
                        Server Group: Any
                      Retention Type: 0 (Fixed)
                     Retention Level: 13 (2 years)
               Alternate Read Server: srvXXXx-xx
               Preserve Multiplexing: false
      Enable Automatic Remote Import: false
                               State: active
                              Source: Operation 1 (backup:dedup.stu.srvXXXx-xx)
                        Operation ID: (none specified)
                     Operation Index: 2
                         Window Name: Default_24x7_Window
                 Window Close Option: SFN
                Deferred Duplication: no
------------------------------------------------------------------------
                                Name: Mensal
                 Data Classification: Platinum
            Duplication Job Priority: 999
                               State: active
                             Version: 7
 Operation  1                Use for: 0 (backup)
                             Storage: dedup.stu.srvXXXx-xx
                         Volume Pool: (none specified)
                        Server Group: (none specified)
                      Retention Type: 0 (Fixed)
                     Retention Level: 1 (1 week)
               Alternate Read Server: (none specified)
               Preserve Multiplexing: false
      Enable Automatic Remote Import: false
                               State: active
                              Source: 0 (client)
                        Operation ID: (none specified)
                     Operation Index: 1
                         Window Name: --
                 Window Close Option: --
                Deferred Duplication: no
 Operation  2                Use for: 1 (duplication)
                             Storage: TandBerg
                         Volume Pool: JFXX-Mensal
                        Server Group: Any
                      Retention Type: 0 (Fixed)
                     Retention Level: 13 (2 years)
               Alternate Read Server: srvXXXx-xx
               Preserve Multiplexing: false
      Enable Automatic Remote Import: false
                               State: active
                              Source: Operation 1 (backup:dedup.stu.srvXXXx-xx)
                        Operation ID: (none specified)
                     Operation Index: 2
                         Window Name: Default_24x7_Window
                 Window Close Option: SFN
                Deferred Duplication: no

 

So now, I created the "...\Veritas\NetBackup\bin\NOexpire" file and ran this command:

> nbstl Mensal -modify_version -version 7 -residence dedup.stu.srvXXXx-XX,TandBerg -pool __NA__,JFXX-Mensal -rl 13,13

And I'm monitoring if the old Mensal SLP will start.

 

An image example that doesn't start/complete:

>bpimagelist -U -backupid srvClientX-xx.xx.XXX1.gov.br_1500089626
Backed Up         Expires       Files       KB  C  Sched Type      On Hold Index
 Status Policy
----------------  ---------- -------- --------  -  --------------- ------- -----
------- ------------
07/15/2017 00:33  07/22/2017      433 390386427  N  Full Backup     0       0
         JFXX-Exch_DAG 

>nbstlutil stlilist -image_incomplete -l -lifecycle Mensal
V7.6.0 I srvClientX-xx.xx.XXX1.gov.br_1500089626 Mensal 2
V7.6.0 C TandBerg 1 1
....

 

Thanks,
Marcio Oliveira

mph999
Level 6
Employee Accredited

I don't suggest that you put the NOexpire inplace, it's not needed unless you start cancelling things.

Also, it should only be used under the direction of support, hence why I mentioned to log a call if that route was needed.

Thanks mph999!

I understood about your considerations, but to me it's unbelivable to agree that doesn't exist a way to change the retention of these images.

So, the only one alternative to us, is to restore these data and backup it again, otherwise to change some parameters of image backup.

I located some similar articles such as:

https://www.veritas.com/support/en_US/article.100014460.html
https://www.veritas.com/support/en_US/article.100015740.html

But my dream was to change the retentions of this images or duplicate it manually (less time and workload, because we have a very big amount of images on this situation).


Thanks,
Marcio Oliveira

Hi, does anyone have an idea or suggestion about this case?

mph999
Level 6
Employee Accredited

You appear to have change copy 1 expire to infinity.  That will only affect new images, images that exist, but have not been duplicated will still have the original time of 1 week, which by now has passed.  Do not cancel these images else they will expire immediately.

The vxlog -o 226 (nbstserv) should show why the duplications are not happening.

It can just be easier to manually duplicate but as the primary copy (copy 1 ) has passed the 'try-to-keep'  time it's a bit harder.  It can be done, using NOexpire and them bpexpdate with -extend_expired option - but I very strongly suggest that this is only done under guidance of support.

I agree, it is somewhat unbelieveable, but, it is impossible to extend the expire time of an image under SLP control, using NBU commands.  It can be done once the image is cancelled from SLP control, but as above, care must be taken.

We not locate the -extend_expired option.

We search in the follow url: https://www.veritas.com/support/en_US/doc/123533878-127136857-0/v123537795-127136857

 

Whe using the NOexpire file, It prevent the image to be expired when cancel the SLP?

mph999
Level 6
Employee Accredited

Just realized you are on 7.6.

-extend_expired is only availble at 7.7.2 via an EEB, or 7.3 onwards as part of the installed product.

I suggest you upgrade, 7.6 is out-of-support anyway.

Yes, NOexpire will prevent the images from being deleted when cancel from SLP, as long as the retention for the SLP is NOT set to 'Expire after Copy'.  It does not protect in this case, and I actually raised this as a bug with Engineering.  Not sure if they fixed it yet, but that will only be in 8.<something> as it wasn't that long ago.

The only other way to adjust the expire time is via manual SQL directly on the nbdb.

In summary, at 7.6 - if you cancel the image with NOexpire in place you will be no better off.

I suggest that you enable the 226 log and look to see what the issue is, it 'might' be fixable.

vxlogcfg -a -p 51216 -o 226 -s DebugLevel=6 -s DiagnosticLevel=6. (on master server)

Leave for at least 24 hours (keep an eye on disk space)

Turn them down 

vxlogcfg -a -p 51216 -o 226 -s DebugLevel=6 -s DiagnosticLevel=6

Convert the raw file

vxlogview -p 51216 -o 226 -t 24:00:00 -d all >somefile.txt

(This will give the last 24 hrs of logs relative to when you run the command, so you may have to adjust the time value).

You will also need the admin log on the maser server.

You will need some of the backupids of stuck images.

Seach the log file for the backupids, this should put you in the approximate area of the file you need to be looking at.  keyswords to look for are bid (as in bid file) batch, the backupid, bpduplicate

When working, you should see the backupid is added to a bid file, and the bpduplicate is construted with the name of the bid of batch file that the image was added into.  This should then be 'run' and you will see the results in the adin log (look for bpduplicte witht the coresponding bid file name).

I suspect here either the image is not added to a bid file, or is added but then removed, or, added but the actual duplicateion fails.