image backup of rx2660 system disk

[Kelly Cox]

I have an rx2600 and rx2660 for development. I have never had any problems and backup anything necessary across the network and to a USB memory stick.

What is the best way to do a standard standalone image backup of the system disk on these units that is supported as a boot device in case of emergency?

[GuentherF]

Slide in a spare disks into one of the bays. Login to your system and makes sure no application is running, no other activity. Stop all print and batch queues.

Do a:

$ BACKUP/IMAGE/IGNORE=INTERLOCK -
SYS$SYSDEVICE: :

Remove the backup disk!

This way you have a bootable disk in case your current system disk fails.

/Guenther

[Kelly Cox]

On pre-itanium class machines you had to boot standalone to create a bootable system disk. I did not think this was possible with a machine running 24 X 365.

Have you tested this?

[EdgarZamora]

Some purists will complain about the possibility of corruption of files open for write, but what Guenther suggested is definitely ok for the purpose of creating a bootable system disk. I do it all the time on a scheduled basis (refreshing my DR servers). As a matter of fact I just copied two system disks that way this morning and booted two new DR servers with those disks.

[Robert Gezelter]

Kelly,

For small systems, the best solution for fast recovery may very well be disk-to-disk.

Of course, open files can be an issue. The important question is: Which open files?

The Gold standard is a standalone backup. Can one use a backup of a running OpenVMS system? Of course. However, there are dangers.

Changes to the open (and active) SYSUAF may not be on the backup. Queue file entries may be a problem. Active database and indexed files can be an issue.

If you have host-based volume shadowing, disconnecting a shadow set member from a momentarily quiesced system is an option. The disconnected member can be remounted (read-only) privately and then imaged to other media.

The true answer is to do a review of the system and files, and ensure that all issues are accounted for.

As a final note, avoid the use of /IGNORE=NOINTERLOCK. This suppresses the warning messages, but does little to truly help you with the problem of getting a good backup.

Lastly, if analyzing the system is a challenge, consider an outside audit (Disclosure: We provide such services). Having recovered systems from problems, it is far better to do the analysis upfront than it is after a crisis has already started.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

If you want the "brainless" recovery path, do follow the VMS documentation and the official directions. This approach has the benefit of by-rote implementation, HP support, and not having to deal with live processes or open files or other such. You get a good backup. Albeit an approach that requires some effort, and involves some downtime.

If you want a different approach, then there are variations available.

The gold standard (locally) is to use a standard disk backup (once a quarter or once a year, and particularly after significant changes), or to maintain the notes necessary to restore from distro, and to then use online archival processing for the application data. (These same notes are a key part of an application deployment process, so you may already have this information, and this repeatability.)

If you have control over your applications, then you can massively improve your chances of getting a solid backup through various changes, while also greatly reducing the downtime required. This can be implemented via a database with on-line archival-processing capabilities underneath the application, or the use of RMS journaling, or implementing your own online archival interlocking and sequencing or online journaling. You may well be able to reach continuous backups with this path, which is something not possible with BACKUP.

BACKUP /IGNORE=INTERLOCK is a comparatively nasty choice on balance, and particularly in a cluster. It doesn't account for caches and active files, and it won't toss diagnostics on open files in various paths within a cluster. It's entirely better than nothing certainly, though how much better than nothing can vary. And how much you want to spend patching your archives back together after Bad Happens. I've patched various of these back together, and with mixed success. Getting the server going is feasible, directly and using distros or other backups. Getting files that were active recovered is not without risk; SYSUAF and otherwise, as well as the application files.

Most files of the VMS system disks (with a few notable exceptions) are comparatively uninteresting, seldom changing, and sometimes problematic to archive. And you can restore from distro. This means doing frequent system disk backup is arguably wasteful in many environments. (If you're making frequent system disk updates and changes, that's another matter and another discussion.)

Treating the Integrity boxes as being embedded platforms or VM guests or images loaded from InfoServer or such, and operating with VMS as a dependency of the application, and this problem can be easier to get your arms around.

And longer-term, you'll obviously need to decide if the available archival features of VMS are sufficient for your application requirements here. That's a very tough call. There have been massive strides forward in online processing and in large-scale distributed databases in recent years, or in reliable and cheap and distributed configurations. Again, longer term, and a tough decision.

Reposting as ITRC is being ITRC.

[GuentherF]

A few more thoughts about an online backup of the sysyem disk.

On a quite system with no write activity to the disk a BACKUP/IMAGE/IGNORE=INTERLOCK produces a disk copy that is-as-good for booting as your current system disk after a crash or power failure.

The state of the system disk before the im backup can be improved by looking at the "$ SHOW DEVICE/FILES SYS$SYSDEVICE". You can ignore all .EXE files listed with no process name. Also most(all) .LOG files. For all other files find out which application uses them and shutdown the application. I typically had a command procedure that processed the "SHOW DEVICE/FILE" output and shutdown application automtaically and warned me of others it could not handle. With that in place your online backup is darn close to a standalone backup.

/Guenther

[Shriniketan Bhagwat]

Hi,

On an IA64 machine while creating the bootable device using image backup, please note the below information.

BACKUP does not preserve GUID signature during an image restore operation of the system disk on IA64 systems. During restore, BACKUP calls SETBOOT to create a new GUID signature. Hence, during an image restore operation, BACKUP does not restore the original GUID signature, but creates a new GUID signature instead. As a result, an IA64 system will not boot automatically from a disk created through an image restore operation.

If required to boot an IA64 system from a disk created through an image restore operation, then either of the two methods described below has to be used to update the GUID signature of the disk.

1. Use SYS$MANAGER:BOOT_OPTIONS.COM procedure to add or validate the boot options.
$ @SYS$MANAGER:BOOT_OPTIONS.COM

2. Use $ SET BOOTBLOCK /INTEGRITY :[VMS$COMMON.SYS$LDR]SYS$EFI.SYS command to update the boot block.

Regards,
Ketan

[tsgdavid · Accepted solution]

Getting back to the original question:

I have an rx2600 and rx2660 for development. I have never had any problems and backup anything necessary across the network and to a USB memory stick.

What is the best way to do a standard standalone image backup of the system disk on these units that is supported as a boot device in case of emergency?

> You can boot from:

- a VMS software distribution CD
- a minimal version of VMS loaded on any of your non-system disks. (You can not restore to the disk that you booted from)
- The system disk using conversational boot and setting STARTUP_P1 to "MIN" to avoid starting all your applications

> You can back up to:

- an IMAGE (bootable) copy on another disk drive
- a saveset on another disk drive
- a saveset on a USB disk drive that was formatted and written on VMS
- a tape drive if you have one

> I have often done VMS backups on-line with /IGNORE=INTERLOCK. This was acceptable on all archetectures for VMS as far back as I can remember, although officially frowned on. If you can shut your system down, do the stand-alone backup with /VERIFY to be absolutely sure. If you consider doing an on-line backup while your applications are running, be aware that some files could be out of sync with each other - particularly if you have a database product on your system disk. Of course, any time you are developing a new backup plan, it is wise to test it by performing a restore (and maybe even documenting the procedure?)

Dave Williams

[Hoff]

This question is cross-posted to the comp.os.vms newsgroup, and there's a discussion out there, too:

http://groups.google.com/group/comp.os.vms/browse_thread/thread/5a92bd1e6c90dd05#

[Hoff]

Ketan raises a very good point about the potential for disk image restoration problems with the EFI console, and the likelihood of skewed GUIDs here.

However, this...

>If required to boot an IA64 system from a disk created through an image restore operation, then either of the two methods described below has to be used to update the GUID signature of the disk.

Isn't the best description of the issue that arises here. It's that the changed GUID causes the console alias entries to fail to find the matching disk. It's that the GUID +has+ changed in the boot structures, and that it now does not match the boot aliases.

The boot aliases contain various details about the target boot partition, including the boot structure sizes and offsets and the unique signature value (GUID) on the disk but - unlike the VAX and Alpha consoles -this value is far more than the physical device. (And rather less than a disk serial number, for those disks that offer that.) If all the GUIDs are unique (and as is the "theory of operations" for EFI), then the particular disk can "float" around in various disk slots, and the EFI console can find it and identify it and boot it... (Not that most system managers would do that, but...)

But if the GUID written to the disk should change, then the EFI console and the existing aliases are inexplicably blind to the volume. Which means you'll have to remove and re-add the boot alias entry at the console (which will pick up the new GUID), or you can boot another system disk (if that's registered as a boot alias) and use the on-line tool to verify and reset the boot alias GUID entry.

This DCL procedure:

$ @SYS$MANAGER:BOOT_OPTIONS.COM

can reset the EFI console boot alias entries when the GUID gets skewed, from what's in the existing boot alias entries, though you can also reset the alias entries directly from the EFI console and skip this. Put another way, when you use EFI to reset the aliases, you don't have to boot some (other) system disk to get at the BOOT_OPTIONS command to reset the EFI aliases. That command verifies and resets the EFI console alias entry as needed.

If you're in a hurry, just follow the EFI sequence for adding a new boot device... That'll be the easiest (though it does require navigating the debacle that is the EFI UI) and fastest approach.

Here's the basic sequence:

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

If you're interested in details of these GUID things, that's here:

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


This command...

>2. Use $ SET BOOTBLOCK /INTEGRITY :[VMS$COMMON.SYS$LDR]SYS$EFI.SYS command to update the boot block.

is an incorrect command in this context.

This command won't reset the EFI console alias.

In particular, this command will derail the earlier BOOT_OPTIONS command, as this SET BOOTBLOCK command doesn't preserve the GUID signature value; it'll change the GUID (again), which is exactly what you're trying to contend with already.

This command is also unnecessary, as BACKUP +should+ be recreating a valid bootblock.

If you +do+ need to reset the bootblock for some reason, but don't want to reset the GUID values (unnecessarily), see the /PRESERVE=SIGNATURES qualifier.

But again, this shouldn't be needed if BACKUP /IMAGE is working as it was intended. And yes, there have been cases where BACKUP /IMAGE wasn't working correctly and didn't reset the boot block.

And FWIW, that SET BOOTBLOCK command is also way too much typing, as you can default that command and (most of) its parameter and qualifiers to something akin to this:

SET BOOTBLOCK ddcu:

and that'll reset the boot block. The command defaults to the current architecture (yes, it works with VAX and Alpha, too) and it also defaults to the boot device specification or boot file path associated with each architecture. You can force the architectures via /ITANIUM (or /I64 or /IA64) or /VAX or /ALPHA, if you're so inclined.

If you're curious about what a boot block is and what it contains, that's here:

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

If you want to see how to do a conversational bootstrap with EFI (which also goes into VMS_LOADER.EFI and related details), that's here:

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

If you're interested in some options around starting a reload or an install from bare iron recovery with EFI, see this:

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

And in general, I'd hope that HP is contemplating placing a user interface atop EFI to ease its use for its end-users. EFI is quite powerful and entirely flexible, but it's also inconsistent and arcane and seemingly intended for system integrators and for very experienced users. As it stands, its quite cryptic and a stumbling block for inexperienced and infrequent users of the Integrity servers. See the boot alias and GUID and BOOT_OPTIONS discussion above, for instance.

[Kelly Cox]

Thanks everyone. I have an external 4mm tape that is supported and spare drives for these I64 units.

The machines can be easily shutdown without offending anyone (me), and I think I'll image the system drive to tape and spare disk on a 'somewhat' regular basis. I do that for my vax and alpha's, i just was wondering if the mighty itanium had some quicker/easier process.

Thanks again for all the input. I got swamped with all my edu clients ramping back up for a new semester, so I have been offline for a few days.