Newsgroups: bit.listserv.banyan-l
Date:         Thu, 20 Aug 1992 13:23:17 BST
From:         ps@JET.UK
Subject:      5.00(5) Retore failure - **WARNING **

*****  ATTACHMENT: help.txt *****

Help!

On Saturday (15th) we upgraded our three aging 386/33 Vines servers with some
new hard disks.

    Configuration was: 300M EDSI & FD
                       Adaptec 1542B (no BIOS) DAT Backup on ID7

    Configuration now: 300M EDSI & FD
                       Adaptec 1542B (BIOS Enabled) SCSI ID7
                       1.2G Byte SCSI Hard Disk     SCSI ID0
                       DAT                          SCSI ID6

VINES Version 5.00(5) with patches 5.00-AM-1, 5.00-AK-1, 5.00-BF-1, 5.00(5)-AR-1
5.00(5)-BA-1, 5.00-AT-1, 5.00-AX-1.

This worked fine, we now have two upgraded servers running 4.11(5) and one
running 5.00(5). Plus two Compaq SystemPro's running 4.11(5) already at 1.2G.
The new drives work fine, and everything works as expected.

NOW HERE COME THE PROBLEMS!

The reason for upgrading is that two of our servers were running out of space,
so once the upgrade was done we proceeded to move the offending files services
to the larger disks.

    on 4.11(5) server about 4,500 DOS files
    on 5.00(5) server about 9,500 (Mainly) MAC Files

1.  When doing a service move on both 4.11(5) and 5.00(5) the MSERVICE utility
    thinks for a long time and then reports "SERVER NOT AVAILABLE" (yes, SERVER
    not SERVICE!) but it is of course. The file service cannot the be started
    and cannot be deleted without the message re-appearing.  The solution is
    to re-start the server. Then in the case of 4.11(5) manually delete the
    files then the service will delete quite happliy.

    On 5.00(5) the file service will delete.

    BTW, once the servcie is in the inconsstant state it does not appear on
    the server "status" screen.

    This BUG (sorry Feature) appears to be related to the number of files in
    the service.  We've tried smaller (test) file services and these move and
    delete OK.

2.  To complete the saga, on our 4.11(5) server, we created a new file service
    with the same name on the larger hard disk, restored the files (all 4,500)
    and everything is OK.

3.  This is where the fun starts,  We tried the smae thing on our 5.00(5)
    server, this appeared to be working fine and all the files were scrolling
    through on the screen. When we got to 1100 od files we got the following
    message (this is from the error log).

      ***** Sat Aug 15 17:48:10 1992
      17:48:10 Starting service rebuild
      17:48:11 ==================================================
      17:48:23 Selected service on tape: Shared_Files@J1_Server@JET
      17:48:23 Selected service on disk: JET_Shared_Files@J1_Server@JET
      17:48:23 ==================================================
      17:48:28 Complete System Backup Rev=5.00 (5), Sat Aug 15 08:32:22 1992
      17:48:29 Restoring JET_Shared_Files@J1_Server@JET
      18:11:08 *** ERROR: vfsexactmatch returned error=1
      18:11:08 *** ERROR: Unexpected error for      100000 /0    14
      18:11:08 *** ERROR: banmain returned error=2112
      18:11:08 *** ERROR:  Restoration unsuccessful. Check Restoration Log.
      18:15:15 ==================================================
      18:15:15    Restoration Summary
      18:15:15 Files Restored:       1159
      18:15:15 Directories Restored: 117
      18:15:15 ==================================================

    Needless to say, the tape passes verification, and we have tried three
    tapes, all fail in the same place.

    It also fails (in what appears to be the same place) if you start the
    file service and then restore "all files" to the service.

    The best bit is that because MAC file attributes (according to Banyan UK)
    are stored seperately (at the end of the tape ??) then although 1159 files
    have been retreived (and I've lost the file space) You can't get them or
    see them.

This raises a couple of issues!

a.  **** WARNING *****  to not trust VINES 5.00(5) to be able to restore your
    file services. Especially if you have large file services, MAC files or
    files with long paths (see later).

b.  If the MAC attributes (or attributes in general) are stored elswhere on
    the backup tape, it that bit is corrupt then you loose the lot!!!
    This is surely *FLAWED* logic on Banyans part.

Thoughts,

Banyan UK are still stumped on what causes the problem, an we still have
screaming (and crying) users.  This could be due to MAC characters or the MACS
using a much longer path, below is an example of the path from where it
failed;

>>>     3584 Aug  5 15:50 Network Trash Folder:Trash Can #2:Steven Bramson
                           :.Steven:.Steven:Misc:PC Misc:CompuAdd DIP Switches

It could just be due to the number of files, but 5.00(5) failed at 1159 and
I suspect this may have been noticed by other people.

What you can do.......

If you are using 5.00(5) and Macs then ** PANIC **, otherwise you sympathies
condolances (and job offers if we don't recover the files) or of course your
thoughts and suggestions can be sent to myself at the address below or to
BANYAN-L.

Addendum

We have now managed to recover some of the files on the backup tape, enough
to keep the important people off our back!  The way to do this is to retore
individual root sub-directories, as opposed to all files.  So far this has
worked, and all the files in the subdirectories come back.  Maybe this is
becuase there are not so many files in a sub-directory. I am not relying on
this method, 'cos we don't know what causes the bug.

Things Banyan don't tell you in the Manual.

The reson it took so long to try this is that we had to figure out what the
sub-directory delimiter was for Mac's, Banyan's example for retore in the
manual only shows it for DOS (and everyone knows what the DOS delimiter is).
To resore a root subdirectory, just type its name in capitals, a second level
directory requires a ":" delimiter, example as below;

    CODAS
    CODAS:DRAWINGS


Regards

Paul Simmonds
VINES Network Manager

+-----------------------+-----------------------------------------------------+
| Paul Simmonds         | Voice  : +235 528822 ext 4609 (+235 464609 direct)  |
| CODAS Division        | FAX    : +235 464404                                |
| JET Joint Undertaking | E-mail : ps@jet.uk (UK & World)                     |
| Abingdon              | X.400  : G=Paul;S=Simmonds;OU=CODAS;ON=JET;PD=JET;  |
| Oxfordshire           |          (C=GB;AD=GOLD 400;  Number:234284400235)   |
| OX14 3EA              |-----------------------------------------------------|
| United Kingdom        | JET is Europe's (EC Funded) Fusion Research Project |
+-----------------------+-----------------------------------------------------+
| Disclaimer: Any views expressed are mine, and do not reflect those of JET   |
+-----------------------------------------------------------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU