HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

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

 
Anjan Ganguly
Frequent Advisor

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

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?
15 REPLIES
The Brit
Honored Contributor

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

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
Trusted Contributor

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

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
Frequent Advisor

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

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

Re: Procedure and Commands to Take Image Backup of Open VMS Ver 7.2-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.
http://www.mpp.mpg.de/~huber
Steven Schweda
Honored Contributor

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

> [...] 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
Trusted Contributor

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

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
Honored Contributor

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

> [...] 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
Honored Contributor

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

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).
A crucible of informative mistakes
Hoff
Honored Contributor

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

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.
Shriniketan Bhagwat
Trusted Contributor

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

Hi,

It was not clear to me from the initial query about what does â corrupted and is highly unreliableâ mean by the author. Since itâ s the image backup of either system disk or of the disk where their customized application is running, I guessed it could be the difference in the copy of the files in the save and the disk. Hence I asked him to use the /IGNORE=INTERLOCK qualifier. I asked to use the /CRC qualifier since the tape used here is DAT. Sorry for not being so clear in my previous reply and thanks for correcting me.

Yes, Offline backups done when booted from CD/DVD or from the minimal boot are most reliable backups.

Regards,
Ketan
Anjan Ganguly
Frequent Advisor

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

The procedure by John is good one.Can I transfer the whole Image Backup to some External Hard drive from the Disk where Backup is taken through FTP?Actually I need to take backup of my system (Almost 20 Alpha Open VMS machine(as said earlier) on every 3 months and I need to keep the older backup also.That is why I want to transfer the backup to some higher capacity USB hard drive where I can have all the Backup Images for future restoration.
Shriniketan Bhagwat
Trusted Contributor

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

Hi Anjan,

I guess you can do it over DECnet.

$ backup/image/verify disk1: node1"username password"::saveset.bck/save

Refer the below link for similar topic.
http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1279260890578+28353475&threadId=1122496

Regards,
Ketan

Shriniketan Bhagwat
Trusted Contributor

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

Hi Anjan,

Refer section 11.5.3 Network Save Sets from HP OpenVMS System Managerâ s Manual, Volume 1: Essentials for more details. Below is the link.

ftp://ftp.hp.com/pub/openvms/doc/AA-PV5MJ-TK.PDF


Regards,
Ketan
Hoff
Honored Contributor

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

>Can I transfer the whole Image Backup to some External Hard drive from the Disk where Backup is taken through FTP?

Yes, and (with VMS) those external drives are typically connected with SCSI. Not USB. Check your hardware configurations to see if you have an external SCSI connector.

As for the network file transfer of the data, you'll either want to preemptively zip the BACKUP (which also reduces the transfer size) or you'll need to reset file attributes when the file arrives back on VMS.

With zip, use the "-V" option to protect the BACKUP metadata. You'll usually need to quote that -V, too.

If you don't take steps to protect the metadata, the usual metadata corruptions that arise when a binary-mode ftp meets a BACKUP can be resolved with the reset tool in the 000TOOLS area of the Freeware, or with a direct SET FILE /ATTR command if your OpenVMS version allows that.

I'd recommend using zip "-V", regardless. Smaller transfers. And the savesets within the zip archives are protected against the metadata corruptions.

When using zip, you can and should use zip 3 and unzip 6; the current stuff. These fix various problems from the older versions.

The available pre-built versions of zip and unzip are intentionally built on a VMS version older than your version of VMS, so you can use them with your V7.2-1 systems.

http://labs.hoffmanlabs.com/node/575
http://labs.hoffmanlabs.com/node/473

>Actually I need to take backup of my system (Almost 20 Alpha Open VMS machine(as said earlier) on every 3 months and I need to keep the older backup also.That is why I want to transfer the backup to some higher capacity USB hard drive where I can have all the Backup Images for future restoration.

USB disks are glacially slow on VMS, and your systems (hardware and software) pre-dates all of that regardless. IDE media operations are also comparatively slow.

If you've got the usual backup window to do this, then get yourself a shelf of (used) SCSI disks, and haul those around, as I'm guessing you don't have extra disks on your boxes. Shelves of seven or fifteen 18 GB or 36 GB drives are cheap, and (how these purchases usually get justified) cheaper than loss of your data. That added storage keep your windows smaller, as it's likely you're not working with gigabit Ethernet (which would be a reasonable upgrade), so those added disks will allow you to cache your backup data (and zipped archives) and then transfer your bootable backups later, and you'll also want a disk for booting OpenVMS to get a copy of your current system disk.

>It was not clear to me from the initial query about what does â  corrupted and is highly unreliableâ  mean by the author. Since itâ  s the image backup of either system disk or of the disk where their customized application is running, I guessed it could be the difference in the copy of the files in the save and the disk. Hence I asked him to use the /IGNORE=INTERLOCK qualifier.

/IGNORE=INTERLOCK removes the anti-data corruption "blade guards". It's the anything-goes switch. It's the switch best used whenever you're creating fake backups. When you're not serious about your data. When you want to have a sort-of BACKUP, and with the potential for subtle corruptions.

For more experienced OpenVMS folks, that switch is what you look for to determine if you're likely to have massive (weird) problems with the recovery.

And I've yet to encounter an /IGNORE=INTERLOCK that worked with a system disk without the requirement to manually rebuild the system disk, and (for various system and application files) blowing those away and rebuilding them.

>I asked to use the /CRC qualifier since the tape used here is DAT. Sorry for not being so clear in my previous reply and thanks for correcting me.

DAT uses its own unique variation of the "WORM" acronym. WORM: Write Once, Read Maybe. Those drives and that media were cheaper than other options for a reason; that stuff is just not particularly reliable.

I've managed to get USB to work on a few Alpha system configurations where it's not officially supported - including on an AlphaStation XP1000 box - but - bluntly - it's glacially slow where it does work:

http://labs.hoffmanlabs.com/node/1410

Haven't tried USB with Alpha with V8.4 yet. And I haven't tried enabling USB with an AlphaServer DS10-class box; it might not even enable.

My recommendation: get some (used) gear including an old SDLT or two and some old disks or an old disk shelf that you can carry around, as that'll likely be a substantial upgrade.
Steven Schweda
Honored Contributor

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

> And I haven't tried enabling USB with an
> AlphaServer DS10-class box; it might not
> even enable.

On my XP1000 systems, I installed (cheap
Chinese) USB PCI cards with one of the
(supported?) NEC chips, and they worked.
Later, after I heard/read that some VMS
version/ECO had enabled the built-in USB
interface on the XP1000, I tried that, too,
and it also worked.

I don't know what's true for built-in USB in
a DS10, but around here the NEC-chip-PCI-card
experiment costs only about $10.

I did manage to find some 5V-only cards which
wouldn't fit into newer 3.3V-only PCI slots,
so, as usual, a little care when shopping
for cheap junk can be wise.