OpenVMS, NSF, and backups

[Dr. Robert Young]

This subject has popped up here and there for over 15 yrs that I can tell. But it is never clear if it "really" works the way it should. At times, people comment "in passing" that they got it working "kinda"...but details are lacking.

Maybe the complete and full answer is hiding on these forums somewhere, but I have obviously missed it if it is (and I may well have missed it...it would not be the first time)...

Basically, I would like to perform image backups of drives on VMS, to storage on a mounted NSF unix based drive. I have a mix of OpenVMS 7.1-8.2 systems.

Is anyone else doing something along these lines????

The intent is to be able to restore a bootable disk should the need arise.

[Bob Blunt]

Robert, you lost me... You want to use what tool to save data from a device connected to which system onto a NFS served disk from or to where?

What I think I heard you ask?

You want to use OpenVMS BACKUP to perform an "image" copy of a disk and you want to put the saveset on a device NFS served from some Unix system. Is that correct?

Some personal points of view. 1) If you want to save the system disk with image then you need to boot Standalone BACKUP or the O/S load CD so no NFS devices will be available. You also will find it most difficult to restore the system disk if you save it to an NFS device served from a different system. 2) Can you use NFS to serve a disk from a non-OpenVMS system to an OpenVMS system and format it as ODS-2 or ODS-5? If so then you should be able to put a BACKUP saveset on that disk just like any other. If it can't be formatted ODS-2 or ODS-5 then I don't believe you can treat it like "just another disk" for OpenVMS and simply telling BACKUP to put output there in a VMS format won't work. Somehow you'd have to treat it like a "tape" or uninitialized disk, mount it /FOREIGN and try to record it.

You also don't say if you're also trying to access the stored savesets from the Unix-served side. I thought that was the main reason for NFS. So you could share files from both from the server and client sides. I'll grant that I'm not intimately familiar with NFS but it seems like success or failure will depend on how that NFS-served disk "looks" to OpenVMS.

bob

[Hoff]

Short answer: test it. See if it works.


Long answer...


>This subject has popped up here and there for over 15 yrs that I can tell.

Ayup. That dates back to around the same time that NFS gained some visibility in the VMS community, and back however many IP versions and patches that was, too.

>The intent is to be able to restore a bootable disk should the need arise.

You'll find that question and the associated alternatives and options date back over thirty years.

Unfortunately for your goal, you cannot directly restore a bootable environment using the path you have chosen here, with either an NFS share or an sftp or ftp copy to a remote server. You need to have the saveset on media that OpenVMS can mount and access during restoration, and the bootable environment is going to be fussy around establishing the necessary NFS access, or sftp'ing the file back to a local environment for the recovery.

Which means the outbound archival stuff works easily, but the inbound restoration path of recreating a bootable disk (from bare server iron) is going to be somewhat more of a project.

If you have enough free disk space on the Alpha to cache the BACKUP locally, then perform the backup locally, look to zip the saveset (with the usual "-V" quoted-dash-capital-V to preserve metadata) and then transfer the file to remote storage via sftp or ftp or other transfer protocols. That is a more direct I/O path for the creation sequence and then for the file transfer, and you'll not have BACKUP hitting NFS directly.

I'd probably use a disk brick or three here, as you can build a bootable environment, and then park the disks on a secure shelf somewhere, rotating through them on a quarterly basis or other such. That can be your intermediate system bootstrap that (also) establishes an environment where you can mount an nfs share or sftp a file or other such. (Disks of the necessary capacity are cheap on the used market, given that folks are running spindles of more than a terabyte or increasingly running big memory and SSDs, and disks of the Alpha era are akin to CRTs in the market.)

Or use groups of disk bricks as your backup, and transport those around as needed. In quantities of a dozen or so, old SCSI bricks are cheaper than tapes. If you happen to drop one or one fails, just replace it.

If your disk capacities are typically dinky (I'm running mostly two terabyte spindles and SSDs and my laptop has more disk space than many Alpha boxes), then the widely-available small (used) DLT drives are cheap, too. And can be directly restored.


> At times, people comment "in passing" that they got it working "kinda"...but details are lacking.

Open-ended questions are not something that can be easily answered, as you're undoubtedly aware.

Try the construction yourself. You have the command sequence used to mount the disk on the Mac OS X box from one of your c.o.v. threads, and you can run a test yourself. You'll want and need to do this testing anyway, just to ensure the backups are recoverable.

As for the "kinda-sorta" history of NFS.

NFS generally kinda mostly sorta works, in general. (The older parallel SCSI gear is in the same kinda-sorta category, the more you know about that. But I digress.)

NFS on older versions was (more) spotty, and NFS on recent versions tends to have fewer issues.

NFSv2 clients often can't be immediately used to connect to most NFS servers, as they're not (by default) exporting something that old; the server needs to be reconfigured.

NFS is upgraded with TCP/IP Services V5.7 ECO2, adding NFSv3 client support (NFSv3 arrived in 1995) with the most recent patches on the most recent releases, and that bypasses the old 32-bit addressing limits (2 GB) that were blowing stuff up.

The NFSv4 series (NFSv4 arrived in 2000, 4.1 is from 2010) includes security and sharing-integrity updates. This version is not available on VMS with TCP/IP Services. This can solve many of the more gnarly problems with NFS; with uncoordinated sharing and corruptions.



And here are comp.os.vms newsgroup discussions that are running in parallel to this thread:

https://groups.google.com/d/topic/comp.os.vms/KhCYl-1F90Y/discussion
https://groups.google.com/d/topic/comp.os.vms/I61QLFJSUoE/discussion

[Dr. Robert Young]

We do a lot of development on our boxes, so there are usually 2-3 BOOTABLE disks w/ DIFFERENT VMS versions on each. So if a single disk "died" , there would always be at least 1 bootable disk that we could come up on, and mount a NSF drive to. Then restore the image saveset that was on the NSF drive back onto the "replacement" disk.

At least that is an idea that was floated. I'm looking into the possibility.

One thing I seem to have noticed, is that image backups seem to be readable if the original drives are in the 2-4 Gb range. But a 36Gb RAID disk causes problems. The saveset to the NFS disk gets to around 4Gb then strange things happen. The "final" saveset may even SUDDENLY shrink by 50% to a file < 2 Gb...and is totally unreadable.

[Hoff]

Based on the new problem statement of development-related activities and the need for software installations and re-installations, and of restoring template versions of VMS, there's an easier approach than NFS.

The easiest and most capable approach here (by far) uses an OpenVS V8.3 or later box (technically V8.2-1 and later, IIRC) and that box runs the Host-based InfoServer software that is part of OpenVMS now.

InfoServer permits both online mounts and allows a console level boot (VAX, Alpha and Itanium), and you can then build up libraries of images to restore, and you can boot the OpenVMS installation via the same mechanism.

None of which is particularly feasible with NFS and OpenVMS; not with the same ease as is Host-based InfoServer.

If you don't have an Alpha or Itanium box that can be used as a dedicated library (nd whatever other purposes that that box might also serve), then the classic (and now very ancient) InfoServer hardware is also still around on the used-equipment market, and the InfoServer software is on the Freeware. (I'd recommend the host-based stuff, as that is newer, easier to manage, and also supports the diskless Itanium bootstrap path.)

As for NFS, and clearly lost in all the replies, is the reference to addressing limits in NFS prior to NFSv3. You're past what NFSv2 supports, and that's the most common client on all but the most recent TCP/IP Services releases. NFSv3 is circa-1995 technology, so it has addressing limits, and NFSv2 and its limits is yet older. NFSv4 (circa 2000, 4.1 circa 2010) is current.

And hopefully you also now have some idea of what has been meant by "kinda" and "sorta" and "mostly" in the context of NFS.

[Hoff]

Clarification: This is correct in general:

/NFSv4 (circa 2000, 4.1 circa 2010) is current/

But was not intended to imply that VMS offers NFSv4.

VMS has only recently deployed NFSv3 client within the TCP/IP Services product, and VMS and various other platforms have not deployed NFSv4 client nor server.

The NFSv4 protocol adds improvements around sharing and security, so it's definitely handy to have that around.

--

For the problem of reloading and reshuffling disk images and LP kits and related, the HBIS pieces are far better suited than is NFS.