Ya, the -virtualnode is another way to do it.
The issue I have with using this method very often is that the
person running the restore command is required to put in the client's
TSM password. We keep that password well guarded as it's shared by
groups of our hosts (with 800 TSM clients, having a different TSM
password for every one would be a pain to track. So we have groups of
hosts with the same TSM client password).
The other 2 ways do not share the TSM client password, as they
use the encrypted file on the host (if you have 'password generate'
enabled in the dsm.opt file.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Friday, April 02, 2004 1:28 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: getting files from another AIX node
>I had a request from a DBA to restore the install data for oracle from
>one AIX node to another. On Windows I have used the virtualnode option
>with success, but on AIX the manual says use the fromnode option.
>
>It seems to go but then says it can't find any files as a result of the
>query, yet the files are backed up on the source AIX node. Anyone ever
>do anything similar?
Just where are you looking in the manual? The Unix B/A Client manual
says: "You can use the virtualnodename option to temporarily access
your node's data
from another machine."
>From ADSM QuickFacts:
-VIRTUALNodenamef vs. -FROMNode -FROMNode and -FROMOwner are
part of the
facility for users sharing
server-stored
files, defined by filename via
Set
Access. -VIRTUALNodename is for
gaining
access to all of a client's
server-stored files while at
another
client (of the same type).
It certainly does work. Make sure that you are doing the query as root;
that the right source-client password is being used; that it the query
is formulated appropriately; and enclose the filespace portion in
braces, if there could be any filespace confusion, as with nested names.
Perform the same query on the source node for comparison.
If still no go, re-post with further details.
Richard Sims http://people.bu.edu/rbs
|