In <Pine.GSO.3.96.980714092551.27723b-100000 AT deceit.anim.dreamworks DOT
com>, on
07/14/98
at 09:53 AM, "Thomas A. La Porte" <tlaporte AT ANIM.DREAMWORKS DOT COM> said:
>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
I saw a similar problem running a 3.1.0.4 fixtext client on solaris with a
3.1.0.3 mvs server. There were only 2 files in the directory. Doing a 'q
backup <path>/*' showed both files, but then a 'restore <path>/*' gave
ANS1092E. We were able to do the restore by specifying enough of the file to
resolve the wildcarding down to one file, i.e. /a* and /b* would restore the
files where /* would not. Also specifying the full filename worked too.
Since we didn't need to be on the fixtest 3104 client we reinstalled the
3103 client and the problem disappeared. This was all documented and
reported to IBM. Obviously there is a serious bug somewhere!
You could get the restore done by taking your SELECT output and generating a
series of 'dsmc res' commands which specify a complete path and file name.
The sql interface is a terrific addition to the administrators bag of
tricks!
--
-----------------------------------------------------------
-----------------------------------------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
-----------------------------------------------------------
=========================================================================
|
