backing up files to solaris host

[Atul Subhedar]

Hi,
I am having a server with openvms 6.2 and I used to take a backup of the drives on the attached tape drive using command,
BACKUP/IMAGE/IGNORE=(INTERLOCK,LABEL)/BLOCK=65534/NOCRC-
/GROUP=0/RECORD/NOASSIST 'drive': 'tapedev':w'drive'.bak/save-
/MEDIA_FORMAT=COMPACT

But now my tape drive had gone bad, and no space to take backup on the harddrive.
I am having a Solaris machine with lot of space on it and also a tape library attached.

now how I can take a backup of the openvms drives on the other solaris machine harddrive so that I can back it up from there ?

Thanks,

Atul

[Steven Schweda]

Buy a tape drive for the VMS system. (Or
another disk drive.)

If you have an NFS client on the VMS system,
you might be able to write a BACKUP save set
to an NFS-remote file system on the Solaris
system, and use "tar" (or something) to get
it onto or back off of tape, but that will
be of little value if (when) your VMS system
disk fails.

And you'd probably need to reduce the BACKUP
block size to a maximum of 32256 for a save
set on disk,

[Hoff]

What was the original drive? What is the VAX or Alpha system and particularly the I/O bus?

If the box is still on OpenVMS V6.2 -- that release is over a dozen years old -- and with the then-typical disk storage hardware configuration, a used tape drive will be a cheap solution for the requirements. And it'll save massively if you have to restore this stuff, and -- if you can find the same drive -- it allows you to restore your existing tapes.

A 35 GB to 40 GB native (70 to 80 GB compressed) DLT drive looks to be selling for about US$100, based on a quick look. (Barring abuse or sheer antiquity, most DLT drives and media are nearly indestructible.) That's probably cheaper than the effort involved in getting an NFS connection working and the subsequent effort involved in transferring and restoring the data.

Yes, you can use remote storage operations, and NFS and such to transfer files around. The comparative difficulty involves restoring the files and recovering from the file structure corruptions that inevitably arrive when BACKUP savesets traverse a non-OpenVMS host.

OpenVMS TCP/IP Services offers an RMT server, though not (IIRC) an RMT client. There's at least one third-party IP stack that offers an RMT client.

Another approach is network-based storage, or adding additional local disk or tape storage. Disks for this vintage are also now cheap.

FWIW, the BACKUP command is shutting off all the redundancy and recovery processing, and is also explicitly allowing silent data corruptions in the output BACKUP saveset. All together, that would imply that the cheapest fix here is to just discontinue the BACKUP. (Collectively, these are the mechanisms that recover from errors and from bad tape media, and that ensure consistency in the recovered and restored data.) That command is mildly hazardous, if the data has value -- but then it's your data, not mine.

Stephen Hoffman
HoffmanLabs

[Atul Subhedar]

Hi,

I got old TLZ 06-VA drive to get installed on my Alpha machine. I am still getting some errors while backing up using the command,
BACKUP/IMAGE/IGNORE=(INTERLOCK,LABEL)/BLOCK=65534/NOCRC-
/GROUP=0/RECORD/NOASSIST 'drive': 'tapedev':w'drive'.bak/save-
/MEDIA_FORMAT=COMPACT

from log I can see some open files errors.
does backup command gives error if files are open ?
Stephen , what is the altenative for backup command .

Regards,

Atul

[Joseph Huber_1]

If there are no hardware errors, then the backup seems to go o.k.
Warnings about "open files" are due to /ignore=interlock for a disk which has active files.

And by the way: Youe are voluntarily disabling error recovery possibility with /NOCRC/GROUP=0.

[Steven Schweda]

> [...] I can see some open files errors.

If you'd let us see them too, we could
probably tell you more about them. Some
messages are normal, some are not. How much
guesswork were you seeking?

BACKUP's /VERIFY option is also popular.

[Hoff]

FWIW: BACKUP with /IGNORE=INTERLOCK does *not* show all of the cases where BACKUP didn't get the data out of the file in a consistent fashion. It shows them where it can reasonably do so, but there are cases where it cannot detect and report same. BACKUP will do the best it can to report and to capture the data, but those interlocks exist to prevent this sort of inconsistency, and you've given BACKUP permission to ignore these data integrity and data consistency interlocks.

There's a write-up of some of the hazards of this command over in the FAQ -- it's just not always the best candidate for an on-line BACKUP. If you have key applications you have control over, you can greatly improve the likelihood that BACKUP or other tools can pick up the critical data and in a consistent fashion.

[Atul Subhedar]

I am attaching 2 logs, one for which I got mail as "backup completed successfully" and other for which I got "backup unsuccessful" message.

I am not able to understand why I am getting backup fail message.

Regards,

Atul

[Hoff]

You're working on a live disk, and the -E- level error triggers your failure path.

The root trigger is likely that the disk is active, and somebody moved or deleted or renamed a file while BACKUP was wandering past. This is a fairly normal case for a BACKUP of an active disk.

An ANALYZE/DISK/REPAIR might find a few items, but I'd tend to assume that you'll see similar errors thrown occasionally by past and future BACKUP passes -- though on various different files.

DCL-level handling of the $STATUS return value from BACKUP can potentially be used to spot this case, but I'd probably also look to scanning the batch logs for error footprints and not to handling errors from the BACKUP command. To post-processing of the text contents of the logs, looking for the footprints of various errors. Heuristics as required.

Clearly CPU and load and time and on-line requirements are in place here. The /NOCRC and /GROUP=0 also shuts off all of the BACKUP-level recovery mechanisms, and entrusts detection and recovery to the drive, and the /IGNORE=INTERLOCK is not without risk to the output saveset consistency.

Details in the FAQ around the general hazards of the /IGNORE=INTERLOCK are in the FAQ; I've always thought that particular mechanism would have been better named /ALLOW=DATA_CORRUPTIONS, just to make the intent of those overridden file system integrity interlocks and around the potential for problems in the output saveset rather more obvious.

[atul sardana]

Dear Atul,

I think as well as you can store data in your solaris server if this server on your network through ftp> in binary mode and revert back when you want.

Atul Sardana