02-23-2018 12:57 PM
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
02-25-2018 03:28 PM
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.
02-26-2018 02:11 AM
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
02-26-2018 02:38 AM
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?
02-26-2018 03:43 AM - edited 02-26-2018 03:49 AM
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
02-26-2018 05:52 AM
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.
03-06-2018 07:51 AM
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
03-16-2018 01:34 PM
Hi, does anyone have an idea or suggestion about this case?
03-18-2018 04:46 PM
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.
04-03-2018 12:10 PM
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?
04-03-2018 01:12 PM
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.