Operating System - OpenVMS
1748112 Members
3463 Online
108758 Solutions
New Discussion юеВ

Re: image backup of rx2660 system disk

 
SOLVED
Go to solution
Kelly Cox
Frequent Advisor

image backup of rx2660 system disk

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?
11 REPLIES 11
GuentherF
Trusted Contributor

Re: image backup of rx2660 system disk

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

Re: image backup of rx2660 system disk

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

Re: image backup of rx2660 system disk

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

Re: image backup of rx2660 system disk

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

Re: image backup of rx2660 system disk

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

Re: image backup of rx2660 system disk

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

Re: image backup of rx2660 system disk

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

Re: image backup of rx2660 system disk

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

Re: image backup of rx2660 system disk

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#