Hi Fred,
first, to check out what was dumped and when at the level of the volume,
you may use "backup volinfo <volume-name>", be sure to use the *full*
volume name you backed up, for instance: "backup volinfo user.fred.backup",
and not "backup volinfo user.fred".
Next, we recently had the same problem: our monthly backup failed almost
at the end, after 116 tapes written. We decided nevertheless to continue
with our incremental schedule (we have two alternating monthly streams,
5 weeks per month and 5 days per week), and the next backup after monthly
(first week), as we understood, nicely had put the missing volumes into
the first weekly tapes (in our case there were only 6 tapes to go (vs
116), so we now will wait for another 4 weeks before the next monthly
backup will clean this situation up).
As you can see from the following output, the volume group.bb in October
is present ONLY in stream1.week1-alt schedule (i.e. it is missing in the
monthly schedule stream1.stream1-alt):
[1] afsbkup@creta:/afsbkup>backup volinfo group.bb.backup
DumpID lvl parentID creation date clone date tape name
812837501 2 812713586 10/04/95 21:11 10/04/95 21:01 stream1.Wed-1-alt.7
812837501 2 812713586 10/04/95 21:11 10/04/95 21:01 stream1.Wed-1-alt.8
812751299 2 812713586 10/03/95 21:14 10/03/95 21:02 stream1.Tue-1-alt.5
812713586 1 812506017 10/03/95 10:46 10/01/95 01:01 stream1.week1-alt.1
812713586 1 812506017 10/03/95 10:46 10/01/95 01:01 stream1.week1-alt.2
812713586 1 812506017 10/03/95 10:46 10/01/95 01:01 stream1.week1-alt.3
812713586 1 812506017 10/03/95 10:46 10/01/95 01:01 stream1.week1-alt.4
812713586 1 812506017 10/03/95 10:46 10/01/95 01:01 stream1.week1-alt.5
812713586 1 812506017 10/03/95 10:46 10/01/95 01:01 stream1.week1-alt.6
[here the monthly master backups were swapped, from stream1 to stream1-alt]
812405462 1 810297421 09/29/95 21:11 09/29/95 21:02 stream1.week5.17
And another volume, user.andrei, is nicely present in the monthly
schedule (stream1.stream1-alt), as it was "lucky" to get in it before
the dump crashed:
[2] afsbkup@creta:/afsbkup>backup volinfo user.andrei.backup
DumpID lvl parentID creation date clone date tape name
812837501 2 812713586 10/04/95 21:11 10/04/95 21:02 stream1.Wed-1-alt.7
812751299 2 812713586 10/03/95 21:14 10/03/95 21:03 stream1.Tue-1-alt.4
812506017 0 0 10/01/95 01:06 10/01/95 01:02 stream1.stream1-alt.43
812506017 0 0 10/01/95 01:06 10/01/95 01:02 stream1.stream1-alt.44
[here the monthly master backups were swapped, from stream1 to stream1-alt]
812405462 1 810297421 09/29/95 21:11 09/29/95 21:03 stream1.week5.13
Conclusion: if your backup crashed (and *why* backup crashes, we have
no idea - in our case we have too many factors to consider, AFS software
being probably the last in the list), you should: 1) check what fraction
of your volumes was dumped (via a small script calling volinfo, for
example, over the list of volumes obtained with listvldb); 2) if the
fraction of volumes not backed-up is reasonably small, continue running
incremental, otherwise re-run the monthly again. In any case, the decision
is all about the number of tapes involved. We have everything automatized,
thus we are not afraid of a small number of extra automatic mounts during
next three weeks.
Regards, ...... Andrei.
PS if you have any further backup questions, you may mail Ruten Gurin
([EMAIL PROTECTED]), he is our backup expert.
____________________________________________________________________________
Andrei Maslennikov phone: +39 6 4463354
CASPUR Inter-Univ. Computing Consortium and INFN fax : +39 6 4957083
c/o Universita' "La Sapienza", 00185 Rome, Italy mail : [EMAIL PROTECTED]
