Many many thanks to Harald Lundberg <hl_at_tekla.fi> and again to Kurt
Carlson <SXKAC_at_orca.alaska.edu> for hints, ideas, help and support!
In short, after 3 weeks of head pounding and screaming, I was able to
get all the users files restored.
I kept trying to recover the older indexes [from before the 4.0
upgrade]. This -never- worked, despite trying various different
tapes/dates & SSIDs. I even tried rolling back to version 3.1A of NSR
[I'm currently using 3.2A], which didn't restore the indexes either.
However, when I recovered the -latest- index, it fixed part of the
problem - it no longer insisted that tape 46 was "corrupted". That was
half the battle.
Eventually I figured out that it wouldn't do any restore that involved
tape 46, so I went through the missing directories piece by piece and
added things that turned out to not be on tape 46. This turned out to be
all but 2 files!
I got the last files back today. It had to be either an index corruption
or a bad tape. To figure this out, I ran 'scanner' on tape 46 [and only
46, i ^Ced out when it wanted the next tape]. Scanner ran cleanly. I
then ran restore, which restored the files!
Previous message follows:
-----------FWD-----------------------
Date: Thu, 5 Sep 1996 15:27:48 -0400 (EDT)
From: Esther Filderman <moose+_at_CMU.EDU>
X-Andrew-Message-Size: 2967+0
Content-Type: X-BE2; 12
If-Type-Unsupported: alter
To: alpha-osf-managers_at_ornl.gov
Subject: [Partial Summary] NSR recover errors
Many thanks to Kurt Carlson [SXKAC_at_orca.alaska.edu] who offered up tons
of advice and suggestions.
I still can't get the data out. Kurt suggested using mminfo to find the
data, then recover on a command line [ie. not using browse] to get the
data off the tape.
I've tried 5 versions of the directory, each time recover insists
there's no data to restore.
I tried to run recoverindex from the tape of the final backup [before
the upgrade], and then from previous tapes, and each time it tells me:
>nsrindexasm -r /usr1/nsr/index/\{server\}/db
>/usr1/nsr/index/\{server\}/db: file exists, overwriting
>\{server\}: 150 records recovered, 0 discarded.
>nsrindexasm: Building indexes for \{server\}...
>query for \{server\}:/var/nsr/index/\{server\}/db failed!
>query for \{server\}:/var/nsr/index/\{server/db failed!
>nsrindexasm: Didn't find earlier versions to recover!
>nsrindexasm: Building indexes for \{server\}...
>nsrindexasm: Suppressing duplicate entries in \{server\} - 7 duplicates
discarded.
>
>WARNING: The on-line index for `\{server\}' was NOT fully recovered.
>There may have been a media error. You can retry the recover, or attempt
>to recover another version of the `\{server\}' index.
Questions: Is it possible this is because we upgraded the version of
NSR during the OS upgrade? Is it possible to downgrade the version of
NSR, get the data off, then reupgrade the version of NSR, and not
corrupt the current backups?
Thanks!
Esther
Original message follows:
-------------------------------------------------------------
Date: Thu, 29 Aug 1996 14:19:52 -0400 (EDT)
Subject: NSR recover errors
Cc:
When we upgraded our 8400 to 4.0, we put the wrong firmware on the
system [the 3.6 disk, it needs the 3.5 disk]. The result was it would
crash about every 10 hours, more frequently if the tz877 was in use.
many of the crashes occurred during backups and restores. One in
particular seems to have corrupted something. It was in the middle of
restoring one user's data [of ~50G of data, only this one user got
corrupted]. Since then, I cannot restore the user's data. Recover
insists that "some tapes had error" [the restore spans 3 tapes] and
actually trying to restore has recover insist that it can't restore any
of the files.
I ran scanner on the last of the backups done before the upgrade, using
"-c servername -i -s ssid". Now it claims it can't get volume info for
the files, and the recover itself complained about an ssid from 3 weeks
before the backup I'm trying to use.
Right now I'm running the scanner on an earlier tape, but this is
probably going to miss some data the user is gonna want.
Is there anything else I can do to get this data back?
Thanks!
-------------------------------------------------------------
Esther Filderman moose+_at_cmu.edu
System Mangler Pittsburgh Supercomputing Center
Member of the NonSequitur society. Our motto:
"We don't have regular meetings, but isn't blue a nice color?"
Received on Tue Sep 10 1996 - 00:36:21 NZST