Procedure and Commands to Take Image Backup of Open VMS Ver 7.2-1.

[Anjan Ganguly]

I like to take an image back up of my Alpha DS10 Open VMS Version 7.2-1 base server in an External USB Hardrive.Presently I am taking it in DAT Tapes which very often gets corrupted and is highly unreliable.And this is forcing me to take image backup in an External Hard Drive(An USB Drive).I am having to SCSI Hard drive of 18.2GB in my system.First one is having Oven VMS Version 7.2-1 OS installed and in the second one our customised applications runs.Can any one help me by provinding the commands to fulfill my requirement?

[The Brit]

Welcome,

The Backup command most likely, is no different to whatever command you are currently using, except that the destination device will change to whatever the device name is for your external disk.

Note however, if you are doing this with the system UP, i.e. with files open, then the image backup is not guaranteed to be perfect. I should say that I have never had a problem booting from this type of backup, it is just not guaranteed.

In order to get a real, guaranteed bootable image backup of your system disk, you should shutdown the system and reboot from an alternate source (OpenVMS distribution CD). You can then mount the system disk Read/Only and back it up will all of the files closed.

HTH

Dave.

[Shriniketan Bhagwat]

Hi Anjan,

I guess external USB drive is not supported on Alpha DS10 with OpenVMS Version 7.2-1. You may not be able to do BACKUP on external USB drive.

>> I am taking it in DAT Tapes which very often gets corrupted and is highly unreliable

Does the error count on the tape drive increases with every operation on it? Does BACKUP report any error when doing BACKUP on to the tape? How old the tape is? If the tape is too old, then itâ s the good time to retire it. What is BACKUP command used?

Regards,
Ketan

[Anjan Ganguly]

The command used is
Backup/image/verify Source: Destination/Machine Name/level=(Your Given name)/media=compact

[Joseph Huber_1]

If you upgrade to a VMS version new enough to support USB disks, still need to verify:

1. does the system model firmware support USB boot ?
2. does backup on the boot CD/DVD support USB disks ?

If none of the 2 questions can be answered "Yes", then make sure there is an additional bootable disk present containing a minimal system for backup, otherwise there is no way to restore the system backup from USB in the emergency case.

[Steven Schweda]

> [...] And this is forcing me to take image
> backup in an External Hard Drive(An USB
> Drive). [...]

Even if it's not possible?

I don't know how things are in your
neighborhood, but around here, it would be
pretty cheap and easy to get another 18GB (or
36GB) SCSI disk. (I often use Sun 611 boxes
for external SCSI disks on my systems.) I
would not bet that you will find a way to
use a USB-connected disk on a VMS version
that old.


> The command used is
> [...] /level= [...]

/LABEL, perhaps ?

[Shriniketan Bhagwat]

Hi Anjan,

>>/level
Do you mean /label qualifier? Use /IGNORE=INTERLOCK and /CRC qualifiers in the BACKUP command. These qualifiers help you make your backup more reliable.

>> often gets corrupted and is highly unreliable
What exactly do you mean by corrupt and unreliable? Do mean BACKUP reporting errors during verification?


Regards,
Ketan

[Steven Schweda]

> [...] Use /IGNORE=INTERLOCK and /CRC
> qualifiers in the BACKUP command. These
> qualifiers help you make your backup more
> reliable.

This must be some new meaning for "reliable".
How would /IGNORE=INTERLOCK affect
reliability? Do you really expect /CRC to
help much on any modern tape drive?

[John Gillings]

re Ketan:

>Use /IGNORE=INTERLOCK and /CRC qualifiers
>in the BACKUP command. These qualifiers
>help you make your backup more reliable.

This is not correct! The only effect of /IGNORE=INTERLOCK is to reduce the severity of an interlock error from E (Error) to W (Warning). That means you only get a warning instead of an error if your backup fails to successfully read a file.

Any file that generates an interlock warning IS EFFECTIVELY NOT BACKED UP!!

Saying /IGNORE=INTERLOCK does NOT "make your backup more reliable", quite the opposite, it tells backup to ignore errors.

In this issue it appears Anjan needs a reliable backup, in case something goes wrong with his upgrade. Given the age of his system, USB is not an option. Go with Steven's advice and do a standalone, disk to disk BACKUP/IMAGE. This will provide the most reliable backup, and a fast recovery path (just swap physical disks).

Shutdown and make a second 18.2GB disk available to the system.
Boot from your OpenVMS OS CD. At the $$$ prompt mount the source and target disks, then:

$$$ BACKUP/IMAGE source-disk: target-disk:

shutdown at completion and remove the ORIGINAL disk as your backup copy (since the new disk will be nicely defragmented).

Repeat for any other disks you want backed up.

Reboot and perform your upgrade, using the new disk.

To restore, shutdown and swap back the original disk.

(Perhaps the folk at Nemonix could come up with a SCSI (& DSSI?) to USB gizmo. SCSI plugs to the host with a USB slot on the other side. Might make this kind of issue easier to deal with).

[Hoff]

If you're on V7.2-1, please expunge any thoughts of "moderan" interconnections and recent i/O widgets and such. That's really old stuff.

The BACKUP /IGNORE=INTERLOCK ignores the file system interlocks, and those interlocks are intended and implemented to provide file integrity; to provide either consistent data, or (when overridden) to generate a warning that the data may not be consistent. One of the more subtle side-effects of ignoring those file system interlocks include various known cases within a cluster where those collisions are not flagged and messages are not generated.

Whether the BACKUP /CRC and /GROUP (CRCs and XOR recovery) provides additional benefit over the typical device-level EDC is not clear (to me).

Why? Whether the tape device will even return any (or enough) data for the BACKUP-level EDC to attempt recovery with the /CRC and /GROUP data in the event of a media-level error is not at all certain.

The /CRC and /GROUP are an implementation from the era when tapes and tape media could return block-evel errors, and had comparatively primitive EDC capabilities. (If any.) Back then, it was common to physically move the tape past the error. Now? Tape errors are either masked, or fatal. (I can't think of the last time I've encountered a BACKUP XORERRS, BLOCKLOST, SOFTRERRS or related diagnostic, for instance.)

Data recovery firms and device vendors may (will?) have specialized firmware that allows specific processing, positioning or recovery techniques beyond the default behaviors, but I'd not expect these capabilities in production firmware. With the advent of streaming tapes such as TU80 and the vacuum tape drives newer - after the era of the TS-11-class "tape stretcher" tape drives and such -- manually positioning media typically isn't feasible.

Beyond the obvious end-to-end integrity testing provided here from the source BACKUP and the restoration BACKUP, it is not entirely clear that there's any particular certainty of recovery from media errors. If the media is sufficiently corrupt to exceed device EDC recovery, I'd not expect BACKUP to have any particular data to work with.

SDLT drives are far more reliable than DAT; media lifetimes on DAT are very low, and are regularly exceeded by roughly a week of a typical daily BACKUP sequence.

In addition to better media ratings, I'd tend to expect better EDC from SDLT from DAT, too.

SDLT drives with capacities of 100 to 160 GB are available for about US$100 on the used market, and less. 18 GB and 36 GB disk drives are also similarly inexpensive. The advantage of gear of this vintage is that comparatively-substantial capacity upgrades are themselves cheap.

I've not seen SCSI to USB.

There are SCSI to ATA and ATAPI device adapters are available, and given the costs of (used) SDLT and real 18 GB and 36 GB drives, and the potential for weirdnesses with those adapters, that's not as advantageous as might be assumed.

Another potential option is platform emulation; that approach can allow you to utilize an x86 box and its hardware. VAX and Alpha emulators are available.

As for the sequences and commands, John has a good introduction, and the Installation and Upgrade manual and the BACKUP manual are the traditional spots for finding out how to use BACKUP.