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

Backup/Restore system disk

 
SOLVED
Go to solution
Mike D'Amico
Occasional Advisor

Backup/Restore system disk

Hello, Under openVMS 7.2 Alpha...If I backup the system disk using the /IMAGE and /IGNORE=INTERLOCK qualifiers, will I have sufficient information to restore the system disk on a different alpha server?

FYI: This image is made weekly with the server online. The backup listing shows some files that were flagged as "%BACKUP-W-ACCONFLICT - file open by another user" but right below the warning it says that the file was copied.
Below is the backup command I used to create the system disk image.

BACKUP/NOASSIST/IMAGE/IGNORE=INTERLOCK-
/LABEL=(DISK00,DISK01,DISK02,DISK03)-
/LIST=DISK0_BCK.LST -
DISK0: mka200:DISK0.Bck-
/MEDIA_FORMAT=COMPACTION/NOCRC- /BLOCK=16384/REWIND

Should I be able to get a successfull restore out of this system disk image? Or, do I have to shutdown the server, boot from the CD and take the system image that way. Just inquiring since this is a 24 x7 machine.
Thanks !!!
16 REPLIES 16
Andy Bustamante
Honored Contributor
Solution

Re: Backup/Restore system disk

The official, documented way to create a system disk backup is while booted from a CD. That being said, it'll most likely work. Expect logs and such to be incomplete. You may need to recreate queues. If the hardware is different, you may also want to run an autogen on the recovered system.

As a general rule, the /NOCRC switch is frowned on. You can find differing opinions on the use depending on who speak with in HP. Since I really want to be able to restore my data, I'll go along with the use /CRC crowd.

One final comment, if you're making a copy of your system on new hardware, you'll need valid licenses for the additional platform.

Andy

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Robert Gezelter
Honored Contributor

Re: Backup/Restore system disk

Mike,

Provided that you are aware of its limitations, yes.

/IGNORE=INTERLOCK will process, but not provide any guarantee of consistency, for any files that are opened for modification. Since the results not consistent, it is not a solution to writing open files.

Typically, this list includes the queue manager files, the UAF, rightslist, and the log and accounting files. Your environment may have other files that are similarly situated.

Provided that you make appropriate precautions to ensure that there are CONSISTENT copies of the critical files elsewhere, this is manageable (e.g., copy the UAF in a safe way to a different file before starting the BACKUP).

With log files and similar files, it would be a good idea to cut-over to new versions (e.g., SET ACCOUNTING/NEW) in advance of the BACKUP.

- Bob Gezelter, http://www.rlgsc.com
Mike D'Amico
Occasional Advisor

Re: Backup/Restore system disk

Thanks Andy, On the License note:

Our plan is to configure/test the new Hardware/OS and Application at its' new location. Once online, we will de-commision the original alpha server in lieu of the new. Given that, will I need new licenses to perform this restore and test? Are the license check sums assocated with the hardware some how? Or is it just a legal transfer to be made at HP?

And one further...Lets say the answer is yes new Licenses are needed. And lets say I contact HP and get the proper information. At what point during the restore do I enter the license information into LMF. Restore, reboot, then plug in the info?
Andy Bustamante
Honored Contributor

Re: Backup/Restore system disk

The licensing issue depends on your original license PAKs. Some of these may be transferable between platforms within an business. The base o/s license generally is not. Another consideration is are you moving between comparable class systems? Units from an Alpha-800 won't do on an ES-45, for example. With VMS 7.2, newer hardware isn't an option, you need to determine what version of VMS and ECOs are required on the destination system.

If your systems meet the license unit requirements, the portablity the next issue. This link may help, http://licensing.hp.com/slm/swl/view.slm?page=contacts#amer.

Andy
If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Mike D'Amico
Occasional Advisor

Re: Backup/Restore system disk

OH Cr_ p!! The orig hardware is an Alpha 8400 and the new hdw is an ES40.

Are you saying I won't be able to restore the system disk from the 8400 to the ES40?

Robert Gezelter
Honored Contributor

Re: Backup/Restore system disk

Mike,

Check the 7.2 SPD to see if the ES40 is supported [I don't have the time to check the SPD at this instant]. That is the relevant issue.

If it is, check to see if there are any patches that only relate to the ES40. If there are, apply them BEFORE moving to the new hardware.

- Bob Gezelter, http://www.rlgsc.com
John Gillings
Honored Contributor

Re: Backup/Restore system disk

Mike,

> will I have sufficient information to
>restore the system disk on a different
>alpha server?

The answer is somewhere between "maybe" and "probably".

Plenty of people will tell you they've been "doing it for years with no problems", but I can tell you that I've fielded 3AM phone calls from people who have an unbootable system after restoring a backup taken with /NOINTERLOCK. So, are you feeling lucky?

It's possible you don't care about SYSUAF, RIGHTSLIST, log files, journals, and all the other open files on the system disk. If so, you'll probably get away with it. If you DO care, you need to shutdown and boot from CD to get a guaranteed clean restore.

If you must avoid downtime, use a hybrid approach... take a BACKUP/IMAGE/IGNORE=INTERLOCK from your system disk to another disk, NOT tape. Make a note of every file that reports ACCONFLICT. DELETE the corresponding file on the new disk and replace it with a CONVERT/SHARE from the running system disk. This is more likely to give you a consistent, clean and bootable disk image.

Transfer the disk to your other system and boot (once it's up, delete the license PAKs from the old system and register the ones for the new system).

A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Backup/Restore system disk

Mike,

>Are you saying I won't be able to restore
>the system disk from the 8400 to the ES40?

I'm fairly sure V7.2 is too old for the ES40. IIRC minimum version is V7.2-2, but you'd be much better off upgrading further. Where you'll find a V7.2-2 kit nearly a decade after its release, I don't know!

If you can get the ES40 booted, apart from the legal issue, your license units will be insufficient, but you'll still be able to boot and login from the console (OPA0) to fix things up.

The OpenVMS base license is bound to the system, at a minimum you'll need to get a valid OPENVMS-ALPHA PAK for the new system. The other PAKs you have may be transferrable.
A crucible of informative mistakes
Andy Bustamante
Honored Contributor

Re: Backup/Restore system disk

VMS 7.2-1 with a TIMA kit was the oldest VMS version supported on an ES-40. As John points out, 7.2-2 was probably the earliest shipping release for that system.

If you're migrating, why not take the opportunity to get a supported release?

Andy
If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
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
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