Server: ADSM V3.1.1.2 on AIX 4.2.1 (F50 RS/6000)
Client: ADSM V3.1.0.3 on IRIX 6.2 (Origin 2000)
I have a very interesting situation that has arisen that I'd like
to share with others in the hopes that I might get some more of
the great feedback that this list always provides.
We recently attemtped (and are still attempting) to restore a set
of files that were deleted on July 2, 1998. Although it would
appear irrelevant in this instance, the RETONLY parameter for
the particular management class to which these files were bound
is set for 180 days. In addition, the files were backed up using
a VIRTUALNODENAME parameter, although that would also appear to
be irrelevant to the problem.
Attempting to do a restore like the following (among many other
unsuccessful attempts):
host [~](POE)(57)> dsmc restore -virtualrootuser=yes -pp=subtree \
? -su=y -inactive -pick -server=dladsm -virtualnodename=poeseq022 \
? "/POE/022/034/2d_cgi/OUTPUT_turbs/*" "/POE/022/034/2d_cgi/"
Gives the result:
ANS1092E No files matching search criteria were found
We have tried many variations on this theme, including among
other things: 1) doing the restore as the root user on the
machine from which the files were originally backed up (but still
using the virtualnodename), 2) doing the restore as the owner of
the files, 3) attempting a point-in-time date restore,
4) attempting to restore each file individually. All of these
have resulted in the same ANS1092E message.
At this point one begins to wonder whether the files were ever
backed up. Enter the wonderful SQL interface that was introduced
with version 3. From an admin session, we do the following:
adsm> select * from backups where node_name ='POESEQ022' and \
cont> hl_name = '/POE/022/034/2d_cgi/OUTPUT_turbs/' and \
cont> ll_name = '0072.tiff' and state = 'INACTIVE_VERSION'
ANR2963W This SQL query may produce a very large result table, or may
require a significant amount of time to compute.
Do you wish to proceed?y
NODE_NAME: POESEQ022
FILESPACE_NAME: /
STATE: INACTIVE_VERSION
TYPE: FILE
HL_NAME: /POE/022/034/2d_cgi/OUTPUT_turbs/
LL_NAME: 0072.tiff
OBJECT_ID: 40212510
BACKUP_DATE: 1998-06-23 22:18:55.000000
DEACTIVATE_DATE: 1998-07-03 04:22:02.000000
OWNER: username
CLASS_NAME: SERVERS
Doing similar queries on all of the desired files produces
similar results. Now we know that ADSM knows about these files,
so we know that there wasn't some crazy thing that prevented
these files from being backed up.
At this point we utilized the 'show bfo ' and 'show inv 0'
commands on a particular object_id to determine on what tape the
files reside. From these commands, and from 'query content'
commands on the resulting volumes, we know that ADSM recognizes
that these files are on those tapes (both primary storage pool
and copy storage pool).
Running an 'audit volume' on the tapes in question results in no
errors being found on the tapes.
So the situation seems to be this: all of the files that I want
are known by the ADSM database. The tapes on which the files are
known, yet no combination of restore or query backup commands is
able to produce a list of these files. If I could read the tapes
raw I would, b/c I know exactly what I'm looking for and on what
tapes. I wonder if anybody has any suggestions, or has seen
any behavior at all like this.
I do have a call open with ADSM support, but the pressure is on
to restore these files (isn't it always), so I thought I'd submit
my situation to the group for consideration.
Thanks.
Thomas A. La Porte
DreamWorks Animation
tlaporte AT dreamworks DOT com
|
