Hello Kathy:
Excerpts from transarc.external.info-afs: 1-Mar-95 backup failure
"Kathryn L. Madison"@sta (2219)
> I'm having problems with backup; afs3.2a, SunOS4.1.3; Sony DAT tape
> drive
Get to AFS 3.3 or AFS 3.3a. There is no upgrade necessary of the backup
database. If you are still running AFS 3.2a fileserver and clients, you
can still run the AFS 3.3 backup binaries (backup, butc, and buserver).
> apparently i have one bad tape; i can get info from "volinfo" for a
> volume, but can't restore it. butc is having trouble reading from
> the tape. if i try to do a "dd" on the tape, that has problems
> too, seemingly with a tape mark.
AFS 3.2 does not distinguish between two tapes having the same name Thus
a tape named "weekly.full.1" dumped one week cannot be differentiated
from the tape "weekly.full.1" dumped the next week. This got messy for
restores since an operator could easily put the wrong tape into the
drive. Especially if it's a date specific restore; or done after
multiple dumps were done because the first few dumps failed for some
reason or another. Can't say for sure if this is what you are seeing
though.
AFS 3.3 uses the dumpid to differentiate the tapes.
> So I figured I would just specify a later date. Unfortunately, I
> seem to have criss-crossed dump levels: i have the following:
> /weekly
> /monday
> /tuesday
> /wednesday
> /thursday
> /archive
> so on one friday, I did /weekly; the following friday, i did /archive;
> during the week after the archive i did /thursday; and Friday afternoon,
> the volumes disappeared (more or less).
> so i try to do a simple restore; it says "weekly" and "thursday" tapes
> required. "weekly" is the one with the problem.
> so i figure i'll just restore from "archive". i use -date on volrestore;
> no such luck. it won't try to restore from "archive" no matter what date
i use.
Date specific restores restore volumes from a dump bases on the time the
dump was recorded in the backup database (its dumpid: see ctime). It's
not until AFS 3.4 that we AFS backup looks at the time the volume was
cloned to do the date-specific restore.
For instance, a volume was cloned at 3AM and butc started writing to
tape at 9PM. You would need to specify the date after 9PM (and not after
3AM) to get the volume off of that dump.
AFS 3.4 backup looks at the clone data of the volume and bases
incremental restores off of that date.
> I figure i can delete "weekly" from the archive -- except that it works
> for the first 30-some volumes. i have gotten savedb to work (after a
> couple tries); if i then remove the "weekly" entry (or entries?) via
> the backup program, will i be able to access "archive"? (I'm going to
> try that while I send out that message.)
> Anyway, I would have thought that reading the tape and piping that in
> to vos restore would have worked...dd with various blockings did get
> the info off the tape, but piping it to vos restore got nothing. I'm
> not sure if it's the blocking factor; or come to think of it,
> volrestore and vos restore might be counting on two completely different
> formats.....BUT is there a way out of this? even if i get backup to
> recognize "archive", there's still an incremental backup based on this
> dead tape, and i would like to retrieve the info if i can.
Butc writes 16KB blocks. If the block size of the tape drive is
something different (not including variable block size), then the
blocking factor will be that (usually it is 512B if it was not set
variable).
> at this point, i'm also kind of
> curious how it works, even if it won't work for me ;-)
The formats are different. Though only in the sense that AFS backup adds
header information around a vos dump. For some help on doing exactly
what you want above, look in
"/afs/transarc.com/public/morin/backup.tape.tools".
WARNING: Use at your own risk. Read the READMEs.
- John Morin.
[EMAIL PROTECTED]
