Backup/Restore system disk

[Mike D'Amico]

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 !!!

[Andy Bustamante · Accepted solution]

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

[Robert Gezelter]

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]

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]

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

[Mike D'Amico]

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]

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]

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).

[John Gillings]

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.

[Andy Bustamante]

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