what is the purpose of grant authority

[magpie73]

During DR drills, we are asked to recover node "abc" as node "abcdr".
We use "Tivoli System backup and restore" to create the rootvg and its odm information to recreate the LVs and mount point on the other VGs.

We use Tivoli Storage Manager to restore the "abc" files to the filesystems on "abcdr", but we are having problems seeing "abc" files from abcdr.

From node "abcdr" the following commands displays no files.
"dsmc query backup -fromnode=abc -subdir=yes -inactive "/home/"

My understanding is that "grant authority" is supposed to facilitate this.
I have tried the following command, but still cannot see "abc" files.
"grant authority abcdr class=node authority=owner node=abc"
I tried this next command - again I cannot see "abc" files.
"grant authority abc class=node authority=owner node=abcdr"

I end up going to node "abc" and using the command
set access b "*" abcdr "*"
Now I can see "abc" files from abcdr.
"dsmc query backup -fromnode=abc -subdir=yes -inactive "/home/"

Unfortunately, in a formal dr drill, we do not have access to node "abc", thus would not be able to enter the "set access" command.

Can anyone clarify the use of "grant authority"?
We need to be able to restore from the command line during the drill, we cannot use browser access.

Thanks.

 

[dhcolesj]

The purpose is to keep just any node from having access to any other nodes data and causing all kinds of problems.

However, if nodeA has granted access to nodeAdr then TSM will allow it to restore "fromnode" or "asnode".

Another way to get around this is to set the node up at your DR site so that it appears to be the original node to TSM. Just set the "nodename" option in the dsm.opt file to be the original node.

The reason you don't normally want to do this is because of scheduling, and hosing up existing data.

If I update the nodename and start the client and add the right password, TSM updates the node's information with a new GUID, and the now current IP address. Come schedule time TSM will try to contact the new IP address (which may not be running the scheduler service).

The other problem is inadvertent overwriting, or removal of the original node's backup data. Such as ASR, System Object, System State, etc. This could cause many problems in the future as well.

All of this is very simplified, and a good read over of some Client Redbooks will give you a better understanding than I can type out here.

 

[tsm_dude]

The grant auth should work, but I just use - on node abc
dsmc -virtualnode=abcd ( need to enter password of node abcd )
Then when you query data you will only see node abcd. Its like you are on that server. Works quite well.

 

[nbloch]

on client side abc, command line, you may also use :
set access backup * abcdr
then run restore on abcdr :
restore -fromnode=abc blablabla
this works fine as well

 

[dhcolesj]

Yep, but I've had trouble with that one on some client versions, and just quit using it.

 

[magpie73]

thanks

Thank you to all for your input. It helped to have some workarounds.