Possible to backup contents of Unix LUN using OpenVMS?

[Jim Geier_1]

We decommissioned a Tru64 Unix AlphaServer system about a year ago. The LUNs for the Unix system still exist on the EVA8000 I manage. The hosts using this EVA8000 are all OpenVMS Alpha or Integrity servers. Would it be possible to present the Unix LUNs to one of the OpenVMS systems, mount the LUNs somehow, and backup the contents to the LTO4 tape libraries used by the OpenVMS systems?

[Steven Schweda · Accepted solution]

MOUNT /FOREIGN, BACKUP /PHYSICAL?

Whether anyone other than BACKUP could make
heads or tails out of the result is another
question. What would you want to do with
this stuff after you got it onto tape?

[Jim Geier_1]

The idea is to get one last backup of the Unix disks before we delete the LUNs from the EVA8000. And, it would take only a couple of LTO4 tapes versus the 6 or 8 DLT-IV tapes used by the last Unix backup. I doubt that we would ever restore the tapes, but if we needed to, we would have to do a restore from OpenVMS and then mount the disks on a Unix system. The more I think about it, the less likely it is that we would do this. But my manager wanted me to find out if it is possible, and that is why I asked.

Is MOUNT/FOREIGN and BACKUP/PHYSICAL the way to accomplish this?

[P Muralidhar Kini]

When BACKUP/PHYSICAL is performed on a volume, it will ignore the volume
structure that is present on the volume. i.e. it is going to blindly do
a block by block copy of the source disk on to the destination.
The requirement for this is for the destination to be at-least as big as
the source disk if not more.

MOUNT/FOREIGN is used to mount a disk that does not have a Files-11 format.

The scenario that you have mentioned -
In the source VMS system, we would do a MOUNT/FOREIGN of the source disk because
it does not have a FILES-11 format. And then do a BACKUP/PHYSICAL because we want
a block by block copy of the source disk as there is no FILES-11 format file system
structure present on the source disk.
This backup would be done to a TAPE.

Later when the data has to be restored, we take the Tape, do a restore to a destination disk on a VMS system. This disk would then be taken to a destination UNIX system for use.

MOUNT/FOREIGN & BACKUP/PHYSICAL should help in this regard.

[Jan van den Ende]

Jim,

>>>
Is MOUNT/FOREIGN and BACKUP/PHYSICAL the way to accomplish this?
<<<

In my view, it is.

But for one potential caveat: restoring has to be done to the same geometry.

So, MAKE SURE YOU HAVE THE EXACT LUN config specification. Make sure to store that with the backups.
Before restoring, (have SAN management) set up the exact same LUN config, and then the restore should do the trick.
If you have enough SAN storage (even temporarily) try the restore before destroying anything.

I agree that it is expected to be unlikely to ever happen, but better save than sorry.

Success.

Proost.

Have one on me.

jpe

[Volker Halle]

Jim,

BACKUP/PHYSICAL is the way to go. It copies block by block from the disk and thus exactly preserves the on-disk information.

I believe I've heard someone describe this technique being successfully used for a CHARON-AXP migration of a Tru64 UNIX system.

Volker.

[Uwe Zessin]

Watch out if this is a Tru64 Version 5 system and one of the EVA virtual disks holds the operating system.

T64 V6 does a "persistent LUN binding" based on a "LUN WWN" - you can see the 128-bit value in Command View EVA on the virtual disk's properties page.

If you restore that data to a disk and cannot restore the "LUN WWN" (an EVA allows this as long as the virtual disk is not presented) it is unlikely that you can do a boot (from SAN).
It is necessary to boot from local media and modify the descriptor files.

[Andy Bustamante]

I have no experience with Tru64, but if you have the Tru64 luns available and one of these includes the operating system, boot one of your Alphaservers as Tru64 and create the final backups.

[Stanley F Quayle]

Can't you hook the LTO4 tape drive to the EVA, at least temporarily?

You should test the usability of whatever backup you produce. If it won't boot, then it's time to go back to the drawing board. Good luck!

[Shriniketan Bhagwat]

Hi,

To BACKUP the disk from Open-VMS, which is other than File-11 format, you need to use the physical BACKUP.

Some points about PHYSICAL BACKUP:

/PHYSICAL specifies that BACKUP is to ignore any volume structure on the input device and is to process the volume in terms of physical blocks. If you write a save set with the BACKUP/PHYSICAL command, you must also restore it with the BACKUP/PHYSICAL command. During physical restore the output device must be either the same size or a larger-capacity disk as compared to the input device. If the output device is larger than the input device, only disk blocks less than the size of the input device are written to the output device. For all physical operations, the output disk cannot have a bad block in any location that corresponds to a good block on the input disk.

Regards,
Ketan