BACKUP of fragmented disk reboots VMS

[BrianT_1]

I have a VMS V5.5-2H4 system and one of the disks is quite fragmented. As a result I'm getting directory allocation failures because of not enough contiguous space to expand the direcories. DFU says its fragmentation state is "poor" (over 3). I want to take the disk offline and perform a backup and restore to defragment it but when I try, part way through the backup, VMS simply reboots. I found a V5.5-2 ECO for backup but it doesn't seem to address the problem. My current backup is:

Image Identification Information
image name: "BACKUP"
image file identification: "VAX 552R_62-000"
link date/time: 4-MAR-1998 17:10:01.46
linker identification: "05-13"

The ECOd BACKUP (VAXBACK4_U2055.A) is

image file identification: "VAX V6.1-008"
link date/time: 26-OCT-1994 08:49:21.76

Would you expect this to help? Is there a BACKUPSHR.EXE to go with it? I notice there isn't one in the ECO kit.

[BrianT_1]

In addition to VAXBACK4_U2055.A on the HP ECO site, I've found VAXBACK05_U2055.A on another VMS V5.5-2H4 system we have with backup image

image file identification: "VAX 552R_62-000"
link date/time: 20-JUL-1995 00:35:27.46

How do I know which of these two is the later version?

[BrianT_1]

Stupid me. I just realized that the BAKCUP image in VAXBACK05_U2055.A is the one I have installed. The question remains, however, which ECO is the later because I didn't see VAXBACK05_U2055.A on the ECO site, only VAXBACK4_U2055.A

[GuentherF]

Oh Brian, you seem to attract trouble. Are you a currator in a computer museum? ;-)

It is not BACKUP that crashes the system. Something else is broke. What was the BACKUP command? Input disk to BACKUP and output device? No crash dump?

/Guenther

[BrianT_1]

GF> Oh Brian, you seem to attract trouble.
GF> Are you a currator in a computer
GF> museum? ;-)

Ha! One might think so. We have about 25-30 VAXes and VAXstations around here that perform some fairly business-critical functions. We develop flight software for and test airborne computers we manufacture with them.

GF> It is not BACKUP that crashes the
GF> system. Something else is broke. What
GF> was the BACKUP command? Input disk to
GF> BACKUP and output device? No crash dump?

A fairly simple

$ backup/image disk: tape:saveset

command will produce the problem. It won't happen right away, but it happens every time during the backup. It has been a while since I last pursued this, so I don't have a dump right now. I can certain generate one, though.

If it's not BACKUP doing it, could it be the tape device? I have a TF85. Sime time the most recent attempt at defragging the drive I had to get the drive in the tape cabinet replaced because it stopped working. Perhaps the crash was just a sign that the drive was failing.

[Art Wiens]

Depending on your storage, do you have the "luxury" of doing the backup to another spindle? That would rule out your tape drive being a problem.

I happen to have a v5.5-2H4 system still as well, it's BACKUP.EXE shows:

image name: "BACKUP"
image file identification: "VAX 552R_62-002"
link date/time: 1-DEC-1999 15:31:17.11
linker identification: "05-13"

If I search through the release notes in SYS$HELP, I find it mentioned in:

VAXY2K01_U2055.RELEASE_NOTES

Kits superseded by this kit:

...
VAXBACK05_U2055 (Backup utility)
...

Good lord man, you're not Y2K compliant!! Planes are going to be falling out the skies!! ;-)

It does read like there were quite a few backup fixes in this patch as well.

And as an aside, reading this and your other recent threads, (and I have no affiliation with the vendor) you really should look into CHARON-VAX. It takes all the "old hardware" worries out of maintaining such relics. It works great!

Cheers,
Art

[Robert Gezelter]

Brian,

If one does not have the disk space, another option is to write the BACKUP save set over DECnet to another node that is better endowed with disk space.

A strong suggestion, particularly with older version is to ensure that the RMS extend, blocking, and buffering factors are commensurate with the situation (hint: default extend is FAR TOO LOW). This can be resolved by including the SET RMS command in the LOGIN.COM for the account being used as the targeet.

I have used the above many times when a tape drive is not available not appropriate (e.g., it is difficult to change tapes from 1,000 miles away).

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> If it's not BACKUP doing it, could it be
> the tape device?

Or the disk? If the cause of the crash is a
complete mystery, why rule in the output
device, but rule out the input device?

Can you do BACKUP of another (comparable)
disk to the same tape drive/medium? Can you
do a similar BACKUP of the problem drive to
NL: (or some other reliable device)? Can you
do a BACKUP /PHYSICAL of the problem disk?
Does ANAL /DISK have anything to say about
the problem disk? (I would try to hold off
on /REPAIR until I knew that I had some kind
of useful BACKUP.) Standalone BACKUP?

[GuentherF]

...or can we have a look at the top few lines from an "SDA> SHOW CRASH" output?

Charon-VAX is not a bad idea. You can run a whole cluster with VAX7000s on you desktop PC. All your HSJ disks can be dropped on a USB-thumb drive.

/Guenther

[Edwin Gersbach_2]

To rule out the output device you could try the following:

$ BACKUP/IMAGE DISK: NL:X.BCK/SAV/LOG

that way you also see the last file copied and can determine the file beeing processed when the system crashes.

Edwin