> I was hoping that a VMS guru could answer a question for me. I have a
> VAXStation 4000 90A and I'm attempting to get a usable backup solution
> for it. The tape unit I've been using on it requires a data stream
> speed that the VAX simply can't keep pushing out to the unit and it's
> casuing physical damage. I have Multinet and I was looking at
> mounting a remote NFS share to the VAX and using the backup command to
> create savesets on the remote NFS server and then put those savesets
> to tape on the remote server.
> I ran this idea past someone who's more familiar with VMS and they
> expressed concern that this plan may not work whenever you attempt to
> restore files from the savesets as "information specific to VMS may be
> lost" but couldn't be clear to me what information that might be. I
> know that you can use backup to create savesets on-disk that function
> identical to those on tape so I'm curious as to if there's any gotchas
> that might be associated with creating backups on a remote NFS share
> disk. The remote computer serving NFS would be Linux or Solaris. If
> anyone could share insight on this plan, I'd be most grateful.
It used to be explicitly stated that BACKUP savesets could not reside
on NFS volumes, or at least could not reside on HP TCPIP Services NFS
volumes. I suppose the issue is that the record size information is not
recorded on an NFS volume - information that is crucial when restoring
from a saveset.
That being the case, you might have to play some games to get it
to work. One of these is to do the backup disk-to-disk, then copy
the saveset to the NFS volume afterwards. Equivalently, you could
use a pipe, say
$ ! Note use of limited blocksize (may be necessary on a VAX)
$ PIPE BACKUP/IMAGE mydisk SYS$OUTPUT:/SAVE/BLOC=4096 | -
COPY SYS$INPUT nfsvol_destination_file
In the latter case you may have trouble with restores because COPY
as an initial pipeline stage feeding into BACKUP will not be able
to convert a stream of bytes into records of the correct size. You
may, however, find that a tool such as EXCHANGE/NETWORK, or a simple
homegrown C program, could do this. With the staging disk approach,
you would copy the file to the staging disk, then use $ SET FILE
/ATTRIBUTES to set its record format and logical record length
before using it as input to VMS BACKUP.
For restores in general, remember that you'll need a bootable
VMS system that includes NFS in order to restore any data. This
makes system disk backups an issue unless you have a spare system
disk available or can restore using another node.
Also: be sure that your NFS connection supports binary files. I don't
know how it works with Multinet, but I believe that with TCPIP Services
you have to make sure there is no automatic translation of data records
to and from STREAM/STREAM_LF.
Another approach is to use ZIP. But you are then of course substituting
a public domain tool with little or no support and unknown reliability
for the highly reliable and well understood VMS BACKUP utility.
Oh, and if it's VMS to VMS, consider using DECnet:
$ BACKUP/IMAGE mydisk node"access control"::saveset/SAVE/BLOCK=...
remembering that you may want to increase the RMS default network block
size at both ends of the network link, say in the LOGIN.COM files or by
issuing a $ SET RMS_DEFAULT/SYSTEM command in SYSTARTUP_VMS.COM .
Quote:> -- Jason McCormick