Problem restoring system disk image from tape.

[dB LEE]

Hi everybody.
I'm managing an AlphaServer 400 running OVMS 7.3 for a small hospital accounting system.

Once per month I boot from an external disk and make an image backup to tape of the system disk. I then restore this image to a second, auxilary, machine as part of our disaster recovery program.
Last month I upgraded the firmware on the auxilary machine and then tried to restore the latest image and failed!
Here are the commands and results I got:
>>> boot -flags E,0 dka600
(...boot from external disk follows...)
$$$ mount/over=id mka500:
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, GCMOS mounted on _SABKUP$MKA500:
$$$ mount/foreign dka0:
%MOUNT-I-MOUNTED, AXPVMSSYS mounted on _SABKUP$DKA0:
$$$ backup/image mka500:gcmos.bck dka0:
%BACKUP-F-MOUNTFOR, MKA500:[SYSEXE]GCMOS.BCK; must be mounted /FOREIGN

I've never seen this message before. Usually the restore operation procedes without complaint. Has anybody got any ideas as to what is going on?
-Dave

[Bojan Nemec]

Dave,

Try just that the error suggest to you:

$$$ mount/foreign mka500:

instead of

$$$ mount/over=id mka500:

Bojan

[Jan van den Ende]

Dave,

try MOUNTing the tape /FOREIGH.

I would guess that that is what you did previously as well...

Proost.

Have one on me.

jpe

[Hoff]

The bootable environment that is included with OpenVMS Alpha distributions has a full set of DCL commands, and looks and works like the classic DCL environment on OpenVMS Alpha.

If you're familiar with OpenVMS VAX and its traditional bootable standalone environment, the OpenVMS Alpha analog is basically full OpenVMS itself; far more than just the BACKUP command of OpenVMS VAX and its Standalone BACKUP environment is present at and available at the OpenVMS Alpha $$$ prompt.

Your use of the system root SYSE could be inferred as having this familiarity.

And FWIW, you should be able to boot dka600: directly, too. You don't need to select a specific root.

[dB LEE]

Thanks for your responses.
I did try the backup operation with the tape mounted /FOREIGN, here are the results:
$$$ dismount mka500:
$$$ mount/foreign mka500:
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, GCMOS mounted on _SABKUP$MKA500:
$$$ backup/image mka500:gcmos.bck dka0:

%SYSTEM-I-MOUNTVER, SABKUP$MKA500: is offline. Mount verification in progress.

%BACKUP-F-GETCHN, error getting device characteristics for DKA0:
-SYSTEM-F-IVIDENT, invalid identifier format
%SYSTEM-I-MOUNTVER, SABKUP$MKA500: has completed mount verification.

$$$

[dB LEE]

Thanks for your responses.
I did try the backup operation with the tape mounted /FOREIGN. After the backup command is issued there is some activity between dka0 and mka0 for about 3 minutes and then failure:
$$$ dismount mka500:
$$$ mount/foreign mka500:
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, GCMOS mounted on _SABKUP$MKA500:
$$$ backup/image mka500:gcmos.bck dka0:

%SYSTEM-I-MOUNTVER, SABKUP$MKA500: is offline. Mount verification in progress.

%BACKUP-F-GETCHN, error getting device characteristics for DKA0:
-SYSTEM-F-IVIDENT, invalid identifier format
%SYSTEM-I-MOUNTVER, SABKUP$MKA500: has completed mount verification.

$$$

[Steven Schweda]

If the tape drive goes into mount
verification, and, at the same time, the disk
triggers a GETCHN complaint, I'd suspect a
SCSI problem of some kind. How stable is the
stuff on the "A" bus? (Or are you attaching
the tape drive just for this exercise, or
...?) Does SHOW ERROR say anything
informative?

[dB LEE]

Hi Steve,
thanks for your reply. I think you may be
on to something... I've had some difficulty
with SCSI on this system in the past.
I physically connect the external tape and boot disk drives for this procedure. The boot disk was created from a 7.3 installation using the PCSI_INSTALL_MIN.COM utility.

Before booting
I set the scsi termination to external since these SCSI devices are not normally connected to the server:
>>> set control_scsi_term external

I work directly from the $$$ command prompt presented after booting:
$$$ dir [*]
Directory SABKUP$DKA600:[SYSE]
...
Directory SABKUP$DKA600:[VMS$COMMON]
...
$$$ show default
SABKUP$DKA600:[SYSEXE]
%DCL-I-INVDEF, SABKUP$DKA600:[SYSEXE] does not exist
$$$ show error
Device Error Count
PKA0: 1
SABKUP$MKA500: 9
$$$

[Steven Schweda]

> [...] I've had some difficulty
> with SCSI on this system in the past.

Assuming that it's single-ended/fast/ultra,
you can pretty easily exceed the total cable
length if it's doing both internal and
external. This has been discussed before:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1152646

1.5m is pretty short, really.

Personally, I'd invest (not much) in a Qlogic
SCSI card (KZPBA-CA/CX), and use that for
(dedicate it to) the external stuff. (Which
is what I do on my XP1000 systems.)

On the other hand, if this stuff normally
works, you could have one of the (other)
usual cable or termination problems. (How
long _are_ the cables?)

[Vladimir Fabecic]

When doing BACKUP/IMAGE restore you also have to MOUNT/FOREIGN destination disk drive.
So it would be like:
$$$ mount/foreign mka500:
$$$ mount/foreign DKA0:
$$$ backup/image/log mka500:gcmos.bck dka0:

[Colin Butcher]

I hope you're powering it all off before attaching things to the SCSI bus. Yes, it will often work OK if there is power on the bus or devices, but it's not a great habit to get into. Much better to leave it all in place all the time and just power things up when you need them.

Always worth using a cleaning tape every so often.

Always worth using /VERIFY every so often - as is proving that you can read the tape on another drive / system.

Cheers, Colin (http://www.xdelta.co.uk).

[The Brit]

Hi Dave,

I see from your comments that you are able to mount the Tape /foreign, however I dont see any evidence that you can explicitly mount the DKA0 device, Have you checked that you can do that?

Also, see Vladimir's response, vis. you need to mount both the tape and the destination disk /FOREIGN.

Dave

[dB LEE]

I have been performing this image backup
procedure for almost a year and have
never had any problems with it until now.

I can successfully mount all the drives.
I can copy files both ways between the tape
and hard drives, both external and internal.

The external tape and boot drives have short
cables and are only connected to the machine
for this particular operation.
CONTROL_SCSI_TERM is set to external.

The procedures I'm using were gleaned from
the Baldwin,Hoffman,Miller book: OVMS Sys.
Management Guide.

I have never heard of mounting the source
target as /FOREIGN. And I've never seen
this error message before.

The only difference to the machine since the last successful image restore is that I upgraded the firmware from V6.3-4 to V7.0-9.
If the upgrade was corrupted would the system
even boot at all?

I do have some other tape drives, perhaps I should try them?

[dB LEE]

OK, I tried the backup operation to a different target:

$$$
$$$ mount/foreign dka300:
%MOUNT-I-MOUNTED, GCMOS mounted on _SABKUP$DKA300:
$$$ mount/foreign mka500:
%MOUNT-I-MOUNTED, GCMOS mounted on _SABKUP$MKA500:
$$$ backup/image mka500:gcmos.bck dka300:
...backup job successful!

And again to the original target:
$$$ mount/foreign mka500:
%MOUNT-I-MOUNTED, GCMOS mounted on _SABKUP$MKA500:
$$$ backup/image mka500:gcmos.bck dka0:
%SYSTEM-I-MOUNTVER, SABKUP$MKA500: is offline. Mount verification in progress.

%BACKUP-F-GETCHN, error getting device characteristics for DKA0:
-SYSTEM-F-IVIDENT, invalid identifier format
%SYSTEM-I-MOUNTVER, SABKUP$MKA500: has completed mount verification.

$$$
So it seems there is some sort of problem
with the dka0: drive.
I'll presue that in a different thread.
Thanks for your help.
-Dave

[Hoff]

FWIW...

Do be cautious with BACKUP commands such as:

backup/image mka500:gcmos.bck dka300:

Leaving BACKUP to decide the source and destination or leaving BACKUP and the drive to decide if the transfer operation worked (or not) has historically been occasionally hazardous practice.

A minimum of:

backup/image -
mka500:gcmos.bck/save/verify -
dka300:

would be my preference.

Also consider using a distro or a BACKUP booted from a newer OpenVMS Alpha release. There have been occasional bugs in BACKUP, in the tape drivers, and elsewhere.

The error log might have an indication of there have been problems in the running system. The GETCHN and IVIDENT and mount verification messages do not bode well.

[Guenther Froehlin]

IVIDENT among other situations is returned when the drive presents an UDID longer than expected.

That DKA0 what brand/model is it?

/Guenther

[dB LEE]

That DKA0 what brand/model is it?
/Guenther

Hi Guenther,
It's an original DEC/Seagate part:
ST35051

>>>show device
dka0.0.0.6.0 DKA0 RZ26N 1103
dka300.3.0.6.0 DKA300 RZ29L-AS 0814
dka600.6.0.6.0 DKA600 QUANTUM VIKING 2.3 NSE 880R
dva0.0.0.0.1 DVA0
mka500.5.0.6.0 MKA500 TLZ09 03a5
ewa0.0.0.13.0 EWA0 00-BB-AA-FF-F2-0F
pka0.7.0.6.0 PKA0 SCSI Bus ID 7

[Guenther Froehlin]

A plain RZ26. As mentioned earlier, make sure your SCSI cabling is ok. And that the last drive (I would set the tape to that) has a SCSI terminator installed.

If you want to further diagnose instead of throwing the RZ26 away, try to do the backup to this drive on another system.

/Guenther

[dB LEE]

mount/foreign
and use /save/verify switches
with short SCSI cables.
Thanks