Post by Neil RieckBack in the day, almost every AlphaServer server hosted a 3.5 inch
floppy drive and there were numerous OpenVMS tools to read/write
DOS-formatted media. (PCDISK, MGPCX, WINFX, etc.)
On the flip side, every Itanium server hosts at least one USB port
if we connected a DOS or Windows formatted drive to the USB port of our
server, is there any OpenVMS software available which could read it?
Wouldn't be my choice. Some of the older-era FAT-reading tools are
listed in section 7.2 of the old OpenVMS FAQ.
http://www.hoffmanlabs.com/vmsfaq/vmsfaq.pdf and there are also some
ODS readers for Windows NT around. Which is clearly the same list that
you're already familiar with.
Post by Neil Rieckps-1: we use a Windows-7 server as an el-cheapo OpenVMS backup
repository for our whole computer room. We create whole-disk save-set
images which are FTP'd to a 1-TB drive on the Windows box each night
over a private 1000-Gb/s ethernet.
I'm going to assume that's gigabit Ethernet network; GbE. Fastest
OpenVMS NICs are 10 GbE models and GbE NICs are common on Itanium and
latter-era Alpha, and Windows has support for yet faster NICs.
Post by Neil RieckSince these drives only cost $100 each, we rotate through a set of 28.
While we have never had to do an emergency restore in over a decade,
I'm just looking for a fast way to get one of the save-sets off the
windows median in an emergency without resorting to using a network
(eg. just plug the windows drive into the USB port)
It'll need to be FAT-format volumes and not the more common NTFS-format
volumes as there are no NTFS readers available for OpenVMS AFAIK.
I'd probably set up an emergency network anew, as a couple of cables
and a Windows box will get you were you need, without having to try to
read and process FAT-format files directly, via USB-device swapping.
But if you do go the FAT-format disk swapping, test it. OpenVMS USB
support was pretty slow for large disks, too. Officially, "USB 2.0
High Speed" allowed 480 Mbps, but even with the USB connection oriented
to allow the bits to flow downhill with a bit-tailwind, I'd expect to
get maybe ~200 Mbps at most and likely less than that.
Given the choice and particularly if you need go-fast recovery, I'd try
scrounging some 10 GbE NICs for the associated boxes, if you don't
already have those. If you need to perform a cold restart and reload
for OpenVMS itself, create a bootable OpenVMS disk with everything you
need to recover the base box (hard disk or optical or USB flash), a GbE
or 10 GbE switch, test it a few times, and then keep that with your
backups.
The OpenVMS boot disk won't change all that often in most environments,
so keeping a copy for three or six months or for a year is often
entirely feasible.
As an alternative to that old Windows Server box and TB USB disk
configuration, 24, 32, 48 TB and larger RAID arrays are easily
available, not all that expensive, and don't involve re-cabling and
avoid tripping over a bazillion separate USB disks and cables.
https://www.promise.com/Products/Pegasus/Pegasus2
https://www.apple.com/mac-mini/
etc. There are other vendors of servers and arrays.
I'd also be running or upgrading Windows and Windows Server to Windows
10 and Windows Server 2016 at this point. 2012 R2 is getting old, and
Windows 7 is ancient.
It wouldn't surprise me to learn that the "official" recommendation
from HPE may well involve a FC HBA and a shared FC tape library or some
such, as a completely different approach.
Use /zip "-V"/ to protect the RMS metadata and the BACKUP saveset
attributes (and with zip 3.0 and unzip 6.0, minimally), and expect to
have to fix any RMS files that have been stored directly on the FAT or
NTFS-format volumes; BACKUP savesets or otherwise.
Or I'd flip this around, and would use the USB disks directly (and
slowly) from OpenVMS, recording the data using the native ODS-5 format,
and storing those disks as your backup. Yeah, you're probably trying
to "split the difference" here between swapping those disks around and
the relative ease of network automation via the network-based copies
dropping all that stuff onto the Windows Server box, most likely.
FWIW, there've been other discussions of reading FAT28-, err,
FAT32-format volumes and other FAT-format volumes here in comp.os.vms,
too. OpenVMS doesn't have any integrated tools for reading or writing
FAT28-, err, FAT32-format volumes AFAIK, and that or a related format
will almost certainly be what you're using here if not NTFS, and what
is around on OpenVMS wasn't (still isn't?) supported for this sort of
usage.
Whatever approach you decide to use here, test it and document it.
One of the other issues with OpenVMS is getting hot backups of live
files, absent a database with that support. But of course we can't
have that database support integrated in some future version, because
reasons.
Post by Neil Rieckps-2: I haven't been able to access http://www.decuslib.com/ for more
than 24-hours now. Is it off the air?
http://downforeveryoneorjustme.com
http://www.digiater.nl
--
Pure Personal Opinion | HoffmanLabs LLC