Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Backup/Restore system disk

 
SOLVED
Go to solution
Jiri_5
Frequent Advisor

Re: Backup/Restore system disk

I check our es-40 servers. oldest version of VMS was 7.1-2 on those systems.
Robert Gezelter
Honored Contributor

Re: Backup/Restore system disk

Jiri,

Andy, John, and myself were referring to oldest "supported" release with regards to the ES40.

It is often possible to run "unsupported" hardware, particularly in the case of a device that appeared shortly into the life of the release, but this is no guarantee of correct function in the face of a problem.

In most cases, the "support" for a new CPU relates to the handling of conditions that do not occur in the course of normal operations (e.g., error handling).

I do not have the time to search the SPDs at this time, but when this question appears in a client context, I always check the SPD or other documentation, and where possible, apply any need upgrades or patches before switching to the new hardware, lest we be surprised when switching systems.

- Bob Gezelter, http://www.rlgsc.com
Highlighted
Jiri_5
Frequent Advisor

Re: Backup/Restore system disk

we bought es-40 in 2000 with 7.1-2 as supported verion of VMS. upgrade to 7.2-1 (7.3) was in 2001 (2002).
Jon Pinkley
Honored Contributor

Re: Backup/Restore system disk

If forum search wasn't broken, I would recommend using it find other threads concerning backup /ignore=interlock, but the forum search doesn't return any thing after 14-Nov-2007. The following Google search will find quite a few:

vms backup /ignore=interlock site:itrc.hp.com

A recent thread was this one:

http://forums12.itrc.hp.com/service/forums/questionanswer.do?&threadId=1191154

I would suggest looking at some of the previous responses.

Good luck,

Jon
it depends
Mike D'Amico
Occasional Advisor

Re: Backup/Restore system disk

Thank you to everyone.. All good points made.
Mike D'Amico
Occasional Advisor

Re: Backup/Restore system disk

Back again... I spoke with our HDW vendor. They will be delivering an ES40 running OVMS 7.2-1 with all of the correct patches/license units applied for that platform. [Same OS version on the 8400 that we are migrating from]. Do you think it would best for me to simply copy over any custom environment dirs to the new system disk and leave the OS as delivered?. The custom dirs are mostly logicals specific for the application that is running. And various DCL utils that we wrote. I guess I would have to re-create the printer queues, the SYSUAF...anything else? Does this seem like an approach? Allbiet - I realize most of you are cringing now cause of the rev level of the OS. For application reasons (to much to list) we are forced to stay with the same OS rev level.
Jon Pinkley
Honored Contributor

Re: Backup/Restore system disk

Mike D'Amico,

Almost certainly you do not want to recreate the "cluster personality files" from scratch. I.e. you should just copy the SYSUAF.DAT, RIGHTSLIST.DAT etc. instead of recreating them. If you are migrating user disks as well, the protection of the files is based on the UIC/identifiers, and if you recreated the above files, it is very likely that the values of some of the UICs or identifiers will change, and then the correct users wonâ t own the files. For the queues, my experience is that a backup /ignore=interlock of an idle system will backup the queue database is a way that the queues/forms/characteristics will be restored, but no entries will be brought along. In most cases, that is a good thing, since if you restore a system disk a month after the backup was done, it is very likely that many timed release jobs will have passed their /after time and will start executing as soon as the queues are started. A good thing to have handy is a command procedure that can recreate your queues, forms and characteristics from scratch. If you use Google, you should be able to find command procedures that will create such command procedures based on your current queue database files.

For a list of these files see Hoff's introductory information on adding nodes to a cluster, and a cluster divorce:

http://64.223.189.234/node/169


I would use the backup utility to copy the files, as it had the ability to preserve more about the files than copy does:

$ backup src:[000000]toplevel.dir dst:[000000]toplevel.dir/own=original
$ backup src:[toplevel...]*.*;* dst:[*...]*.*;*/own=orig/truncate

Will duplicate the [toplevel] directory and all its subdirectories and files with the original file security information (ownership/protection/ACLs), and will use the minimum amount of disk space needed on the destination disk (/truncate). This is especially important if the clustersize on the destination disk is different from (and relatively prime to) the clustersize of the source disk.
restored.

Other issues you many need to consider. If you have layered products, you will need to resister/load the license PAKs. If your software allows a transfer, then the units issue shouldn't be a factor, as the units for an 8400 will be larger than an ES40.

If your startup command procedures have hardcoded device names, it is time to change them to use logical names. That can be done before the move, so you don't have nasty surprises the day you move.

If your node name is changing, you may need to modify the licenses to reserve them to a different node. BTW, this is one area that license/issue/procedure does not do everything needed to be able to recreate the license database from the command file it creates.

You will definitely want to do a dry run on the new system before the move, i.e. take boot the new system from a CD, and get a complete backup of the drive as it was delivered to you, or if you have disk space, a second bootable disk copy. This is your "baseline". Now do your restore from tapes, etc and keep a good record of what you do. When you are done, your new system should be a logical clone of the original, and should behave identically (given limitations of the hardware configuration). Have people test what can be tested. You will probably find some things that break because of assumptions made by command procedures (the killer is disk references like

$ open/read/error=custdata_openerr infile $6$DKA200:[DATA]CUSTOMER.DAT

and the data that was on $6$DKA200 is now on $1$DGA302. Much better to use something like

$ open/read/error=custdata_openerr infile DISK$DATA:[DATA]CUSTOMER.DAT
it depends