Correction on the report below: When we duplicated the problem restoring
only on the path & file in question (instead of a whole volume for the sake
of time), ADSM was not asking for the tape that was processed via MOVE DATA
as reported below (Tape A00008). The tape mount was called from a second
management class in which the physical client is enrolled (Tape A00012)
under a different node name (Management Class A = AEGIS; Management Class B
name = AEGIS_YELLOW). We fed tape A00012 and the restore processed.
Therefore, at least one file didn't make the restore. We can't be sure of
the others which would have followed.
Both management classes run from a common database. Both management classes
run nightly backups in parallel. This allows us to maintain (2) different
data retention policies within backup (reasons/logic omitted here).
To re-frame my question(s):
- Why wasn't the data available from the Management Class A DASD storage
after the MOVE DATA?
- Why would a restore from Management Class A call for a media mount from
Management Class B?
- Does this suggest a problem with keeping active and inactive files
separate?
Thanks, and sorry for the erroneous 1st report.
Steve Kuhn, Network Manager, Aegis Insurance Services, Inc., Jersey City NJ
kuhns%aegis AT mcimail DOT com 201.521.4565
_____________________
We are mopping up from a Netware 3.12 disaster recovery restore using ADSM v
2.x clients and an AS/400 v.1x server. Approximately 50% of the data for
the server was stored on 8mm tape which was set up as a NEXTSTGPOOL for
AS/400 DASD volume. During the restore, we started a MOVE DATA from tape
back to the DASD volume in advance of any calls for tape mounts, to assure
that everything was in from tape and on DASD for fastest restore. The MOVE
DATA completed before the client asked for a tape mount, and the tape volume
shows 0.0% utilization.
During the restore, we experienced a TCP/IP error and needed to begin again.
As the restore progressed, we made the system available to users and files
were being updated as data continued to come down from the AS/400. As a
safety measure to assure that all data was back (without overwriting new
updates) we ran:
LOAD <path>\DSMC RESTORE -SU=YES -REPL=NO DATA:*
Near the end of the above run, we rec'd a message calling for a tape mount
for the volume that had been MOVEd. Since it occured in the middle of the
night, the session timed out waiting for a reply.
If we believe the Q VOL and MOVE DATA results, we must assume that the call
for a tape mount is in error, probably from an error in the database
entries.
Any input would be greatly appreciated.
Steve Kuhn, Network Manager, Aegis Insurance Services, Inc., Jersey City NJ
kuhns%aegis AT mcimail DOT com 201.521.4565
|
