always problem on RMAN restores

[manatee]

NBU 7.7.3, Solaris 11

last Friday, i had the weirdest restore scenario. whatever we do, NBU prevents us from doing an alternate RMAN restore. i have checked:

1. bp.conf = DISALLOW_CLIENT_LIST_RESTORE = NO and DISALLOW_CLIENT_RESTORE = NO
2. same also in the GUI properties of master server, all clients are not prevented
3. if i do "bpclient -client test -L" i get:
   1. Free Browse: Allow
   2. List Restore:  Not Specified
4. the username and group are the same from source client and destination client

so the work around i found is to list the destination client in the master server properties / Servers tab. then it allowed me to do RMAN restores.

why is it that with RMAN, we always encounter different problems requiring different fixes just to do a restore?

[quebek]

In order to perform so called redirected restore you need to do following:

create a touch file called No.Restrictions in /usr/openv/netbackup/db/altnames directory

or in the same location create a file name after destination client name (the one from which you do restore) 

You may want to review these:

https://www.veritas.com/support/en_US/article.000073334

https://www.veritas.com/support/en_US/article.000120329

[quebek]

and example for your scenario

Description

Example - Performing a redirected restore of Oracle

https://www.veritas.com/support/en_US/article.000073307

[manatee]

hi,

sorry forgot to mention that i've also created the "No.Restrictions" file and filename of the client too.

however, even with that, NBU is preventing me to do a restore. as i've mentioned, the only way it allowed me is to list the destination client in the master server's properties/Servers tab.

as for the additional problems today, because i'm doing a verbose=5 restores, the logs/dbclient folder got filled up. that's all! after deleting all logs the restore went thru. weird isn't it? even the restore error doesn't mention it doesn't have space to do a verbose log.

[quebek]

Well maybe your destiantion client is multihomed - has multiple NICs and it is reaching out to your master via different name, but from other hand the No.Restrictions should have allow. Wierd... I never faced such issue...

You can check maybe the bprd log on master who is requesting these backups and react accordingly... Strange... I have most of my sites on 773 and did not see such misbehaviour...

[Marianne]

Do you have bprd log folder on the master server?

This is where we will see how the restore request is interpreted by the master and why restore request is rejected.

Level 0 or 1 log is fine here. Remember that NBU must be restarted for bprd log to be enabled.

PS:
It is hardly ever that you need level 5 log. I only ever enable level 5 when a Support call is logged with Veritas and they request level 5 logs.

[Nicolai]

Before attempting a Oracle clone, you can test if client as access permission to restore data from "other" client by using the bplist command:

# bplist -B -C ora.acme.com -R -l -t 4 -s 01/01/2017 /

-C will be the client that did the orginal backup. If bplist does not return any data permission isn't correct (or bplist argument is incomplete). If permission is in place, bplist should return Oracle backp made on the source.

[Marianne]

@manatee it seems that Oracle restores were working prior to this?

https://vox.veritas.com/t5/NetBackup/can-RMAN-actions-be-restricted-controlled/td-p/775232

I have never seen the need to add the destination client in the master server properties / Servers tab.

Please tell us what the exact error message is that you are experiencing and post bprd log (as .txt attachments).

[manatee]

true. but we clone to many machines (solaris zones) and each always comes with different ways or errors of NBU restores. this last one is really weird with the work around i have to implement. first time.

 note: i only have a bprd log which was created before i add the destination client to the server's tab of master server properties. so its kinda old.