System Disk Backup

[Thomas Marian]

I'm a relative newbie to OpenVMS, having been pressed into service by my predecessors demise.
I think I read somewhere that it is no longer necessary to use an image backup to backup the system disk. Is this true, and if it is, how?
Would you use a bootable floppy or cd, format the disk with a startup (sector?) and the just copy a regular backup of the disk?

[Steven Schweda]

It's not necessary to do _any_ backup, if you
don't plan to lose any data. If you decide
not to take that chance, and if you would
like a complete and consistent backup of the
system disk, then BACKUP /IMAGE is about the
only option.

If you don't want any files open when you do
the backup, then it's wise to boot from some
other disk (or, on old VAXes, tape). A VMS
installation CD-ROM is a popular choice.

I'm pretty sure that this all is covered
somewhere under:

http://h71000.www7.hp.com/doc/index.html
http://h71000.www7.hp.com/doc/os83_index.html
http://h71000.www7.hp.com/doc/82FINAL/aa-pv5mj-tk/aa-pv5mj-tk.HTMl

or thereabouts.

[Hoff · Accepted solution]

You might have read that it's no longer necessary to archive the system disk in the context of having reliable copies of the core files -- and an BACKUP/IMAGE of the static contents of the system disk (made after each round of patches or kit installations, for instance), or a willingness to reinstall from distro. This involves performing regular BACKUPs of the critical files, either on the system disk or located on another spindle.

It's feasible to stitch a disk back together from a file-oriented BACKUP, but it's not necessarily going to be bootable. There are a set of system directory alias entries that need to be re-aliased, at a minimum. And for some of the magic and risk of an on-line BACKUP, search the (text or PDF) OpenVMS FAQ http://www.hoffmanlabs.com/vmsfaq for the discussion there around /IGNORE=INTERLOCK, and the risks of same.

It's also feasible to quiesce activity and to split off a shadowset member volume. If you're using shadowing. I haven't seen a write-up on that approach, and might well doubt that HP would officially support the results as always being restorable. But there are folks that do use that approach.

But as the earlier response indicated, you only need archive that which you value. (I've also posted up pointers to two recent large-scale studies of disk failures over at http://64.223.189.234/node/93 )

(I should post an article with the steps usually involved in re-stitching the system disk back together from a file-based BACKUP, if not a second one on shadowset operations, but that's fodder for another discussion and another time.)

The OpenVMS system manager's essentials manual is a good start, and that's available at http://www.hp.com/go/openvms/doc
That'll bring you up on the basic issues, and give you some help reviewing what is and needs to be done with the systems -- a review and an update of your OpenVMS environment, as required.

Stephen Hoffman
HoffmanLabs

[Robert Gezelter]

Thomas,

No, I would still recommend an image backup is the appropriate course of action. It is the surest way to ensure a simple response to the loss of a system disk.

Other approaches can work, but they often involve more ad hoc work when there is a problem. The combination of ad hoc work, and low experience is a high risk situation. Yes, I have reconstructed system disks for clients who did not have an image backup, it was successful, but it does increase everybody's (read: management's) anxiety level.

The shadow copy approach is appropriate, but you should still be making an off-array image copy of the split-off member.

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

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

[John Gillings]

Thomas,

IMHO the most important thing to know about backing up your system disk is that most of the files you really want to backup (because they change frequently, like SYSUAF, RIGHTSLIST and friends) are open all the time, and therefore CANNOT be reliably backed up using the BACKUP command. You will need to find an alternate mechanism to take a useable snapshot of these files, preferably to another disk. My favourite is to use CONVERT/SHARE. Keep "hot" copies on another disk. These can be safely backed up as they're not open, and you have immediately available copuies on the spare disk.

Conversely, most of the files you CAN backup never change and are available on distribution media, so you don't really need to back them up, so why waste time and resources on them?

To reproduce a system disk you MUST use /IMAGE, as it's the only way to preserve the cluster common disk structure, and avoid taking multiple copies of files which are accessible through alternate directory paths. So, take a BACKUP/IMAGE after you upgrade or patch your system. Recover by restoring that image, then copy in the latest versions of the volatile files.

See the paper "OpenVMS Backup Theory and practice" in OpenVMS Technical Journal V1 http://h71000.www7.hp.com/openvms/journal/v1/index.html for some hints.

Further gratuitious personal opinion - I don't like tape at all. Spend the money and do all your backups direct disk to disk images. When you come to restore and discover it's as simple as unplugging the old, plugging in the backup and booting, you'll realise the value of the investement.

[Martin Hughes]

I'd suggest that the backup method involving dismounting shadowset members is not the best option if you are new to VMS. At least not for a regular backup. There are a number of considerations in whether this is appropriate, and it will take some reasonable skill to automate a water-tight solution.

What you might want to do is take a standalone backup with the system booted from CD (I.E. so the system disk is not being written to), and do regular backups with the system up. In most circumstances your regular backups will be ok, despite being taken while the system disk was being written to. In the worst case scenario, you can go back to your standalone backup. I would use /IMAGE for both backups.

And take a standalone backup again if/when you make a significant change to the system disk, such as an operating system upgrade.

[Robert Gezelter]

Martin,

Actually, I often use a solution along the lines of what John described.

For 99.99999% of the system disk, you do not need standalone. The few files that are affected are often the SYSUAF and related files, which can be backed up as John described.

The Shadowset solution does indeed require care, but it has the potential for being the fastest. The complexity depends upon your situation.

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

[Steven Schweda]

Note: Strictly speaking, "Standalone BACKUP"
is a VAX-only thing with very limited
capabilities, and should not be confused with
the more elaborate, close-to-normal VMS
environment which is available when booting
from, say, a VMS installation CD-ROM.

Even on a VAX, the more recent installation
CD-ROMs offer more than Standalone BACKUP in
the SYS1 directory, as the manual says. I'd
have to check, but I suspect that the VAX
CD-ROM has Standalone BACKUP in SYS0 (the
usual default), and perhaps in SYSE (another
common place to find Standalone BACKUP).

As the original inquiry lacked a few details,
such as which hardware and OS version we're
discussing, it's hard to get very specific
about the details. (Because he did mention a
"cd", we can probably assume that we're not
talking about a VAX 11/780, but much more
than that is difficult to divine. "Eenie
meenie, chili beanie, the spirits are about
to speak! ...")

[Martin Hughes]

I must admit, I hadn't previously heard of the solution John suggests. I'll have a look into it.

ps: I didn't actually mean standalone backup, I just borrowed the terminology (perhaps inappropriately) to refer to a system booted from CD.

[EdgarZamora_1]

A lot of people us the CD distro to boot and backup the system disk. I prefer using the son of standalone backup. I don't know if it's still available after 7.3-2 but as of 7.3-2 it still is. I just created a SYSE root the other day on one of my "data" disks.

DRCLCC> @sys$update:stabackit

Standalone Backup is no longer part of the OpenVMS Alpha operating
system. Please refer to the "Backing Up and Restoring the System
Disk" appendix in the "OpenVMS Alpha Upgrade and Installation
Manual" for more information.

After reading the information in the manual, you may wish to use
the procedure SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM to install
OpenVMS Alpha without any optional features on one or more of your
"data disks".

Do you wish to invoke SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM? [Yes/No] y

...executing @SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM



This procedure will allow you to install OpenVMS Alpha with no options
on a disk other than your regular system disk. You can then boot
from the other disk to backup your system disk.

You must enter the device name for the target disk. Before this
procedure is run, the target disk must be mounted privately to this
process. This means that it must not be mounted with /SYSTEM,
/CLUSTER, /GROUP or /SHARE qualifiers. It also must not be mounted
with the /FOREIGN qualifier. If any of these qualifiers were used
when the disk was mounted, dismount it and re-mount it without them.

(If you need to MOUNT enter Ctrl/Y to exit.)


Enter device name for target disk: (? for choices)