OpenVMS Decnet + backup command

[geir_2]

Hi,

I want to transfer an image ($backup/image) from one server to another. I have tried different commands without . success.

$backup/image/ignore=interlock 1.80"username password"::dka100 user.bck/save

The error message indicate that it's an illegal backup device.

Since the source server have no space to store the image locally I want to run the backup command from one server to antorher. We use Decnet Phase 4+. Hope someone could give me some usefull hints. Thanks:

[Volker Halle]

Geir,

please show the complete command and error message (using cut & paste - if possible):

The correct command would be:

$ backup/image/ignore=interlock 1.80"username password"::dka100_user.bck/save

Your original command included a SPACE character in the output saveset parameter. This could have led to the error message about an invalid device.

Volker.

[Richard Brodie_1]

The saveset has to be on the remote node: you can push a sequential file over DECNET but you can't rummage around in the innards of a remote disk.

[Volker Halle]

Geir,

sorry I've overlooked the missing input device specifier in your command example. So a correct BACKUP command would look like this:

$ backup/image/ignore=interlock dka100: 1.80"username password"::user.bck/save

The input disk MUST be a local disk, but the output saveset can be on a remote node.

Volker.

[geir_2]

Hi,

Thanks for all answers.   I try to copy a image file from one server to another . Each time I try to execute the command I got an error message. The command I run is following:

$backup mka500:osws99.bck/save 1.99"system password"::dka100:osws99.bck

osws99.bck is a image file.

The tapedevice is mounted with the foreign command

Rgds

Geir

Maybe it's not possible to move a bck file from one server to another with the backup command.

[Hoff]

A saveset specification is the only portion of the BACKUP input and output parameters that's permitted to be on a remote (DECnet FAL connected) host.

You're trying to reverse this pattern, and place the saveset locally and to then restore the files remotely, or to copy the file remotely.  That won't work, as BACKUP would have to open a gazillion files over the network, and that was viewed as problematic by the folks that built BACKUP.

You can read the examples in the BACKUP on-line HELP text for typical commands. 

Looking at the specifics of your question, this particular question has arisen fairly regularly over the years, where you don't have a tape drive on the target system that is compatible with the media, and where you don't have a scratch disk local to the tape drive you do have.  You can temporarily move the tape drive to the target system, or free up some storage locally, or you can cluster the hosts (if you have licenses), or you can temporarily transfer some disk storage from the target system over to the system with the tape drive.  

You can potentially also try to MOUNT the tape native, and attempt to COPY the saveset from tape to disk, then transfer the saveset to the remote host for restoration.  That isn't entirely reliable and won't work for multi-volume savesets, and HP/Compaq/DEC offered the Saveset Manager tool to perform that operation more reliably.

The best solution is acquiring the additional hardware necessary; additional used or new tape drives, or that could be more storage on the systems, or some shelves of disk drives that (with the proper care around quescing the SCSI buses) can be swapped around.

Best?  Get yourself a tape drive.  That'll make backups on the remote server easier and faster, too.

And FWIW, using /IGNORE=INTERLOCK is a recipe for silent data loss.

[geir_2]

Thanks for the answer.  Our problem is that the desitnatoin server doest not have any tape drive, and the source server have no disk space sufficient to store the image file temporary.

Maybe I should try to use the copy command, but what do you mean with mount the tape native?

Thnaks again,.

Rgds

Geir

[Hoff]

The use of "native" here refers to the native file system and avoiding a so-called "foreign" file system MOUNT operation; to specifically to issuing the MOUNT command without the /FOREIGN qualifier.

MOUNT /OVERRIDE=ID mka500:  

COPY mka500:[000000]osws99.bck 1.99"user password"::osws99.bck

This sequence might not work.  This sequence will not work if this is a multi-volume tape saveset; if there is more than one tape involved.  This sequence will also not work if there were large block sizes selected when the BACKUP saveset was created.

Get a SCSI tape drive that is compatible with the media you are using in the MKA500: device, or get additional (used, larger) disk drives or increased disk storage capacity, or (likely where you will end up, inferring from the arc of this thread) shut down both servers and temporarily transfer the current SCSI tape drive MKA500: to the target system, perform the BACKUP restoration, and then shutdown both servers and transfer the tape drive back to the original system.

And FWIW, we have probably already inferred far more here than you might have realized.

edit: fixed the host name and specifications to match your example.

[Bob Blunt]

Hoff's recommendation to find and purchase a tape drive for the systems is your best solution.  Using the network to funnel your save operations can be a potential solution but it is one that can have serious challenges.

There is a really old DECnet hack using task-to-task communication with simple command procedures that has been used when one system has a tape drive and the other doesn't.  Again, as Hoff said, this idea is not the safest or most flexible solution.  If your backup requires more than one tape it will NOT work.

Moving the tape to the system that needs it is an easy fix (provided the systems are in the same room).  Buying another tape doesn't have to be very expensive.

Figure out your needs, how many tapes it takes to save the data, etc.  Then decide which solution is best for your circumstances.  Please consider one last scenario, though.  What happens if you have to recover the whole system that has no tape from the ground up?  If you don't have an operating system at all then you can't restore from a remote tape (or disk).  To twist this another way?  What do you do if the remote node storing the savesets is broken and you have to recover?  My feeling is that it is easier and ultimately cheaper to have a tape per node.

bob

(however, if you're unable to see the logic then you might Google for a string using OpenVMS BACKUP SYS$NET CONVERT)

[Hoff]

Some consideration was given to posting a link to the DECnet task-to-task DCL procedure (here is an article on that topic), but that is probably more than what the OP wants to deal with here, and that example DCL also gets the disk data from the host disk to the remote drive.  Not back again.  This thread is the data-restoration sequence, and that DECnet DCL doesn't provide a path for that; this current sequence is the drawback.  This particularly if it is your boot disk that you are backing up on the remote server; the box without the tape drive.