Boot OPENVMS 7.3-2 from SAN

[Pete Maurer]

I was successful in booting an ES40 server from the SAN today. However, I ran into a problem when testing a DR scenario. I used
Innovation's FDRSOS to backup the OS and lay
the OS back down. The reboot from SAN failed because it appears I didn't recover the bootstrap.

Halted CPU0 - Kernel stack not found.

I get past the problem using the VMS 'Backup'
utility, but I would like to use FDRSOS.

So, I was wondering if there's a way to load the bootstrap on SAN storage from the OpenVMS boot prompt ???

Thanks!

[Andy Bustamante · Accepted solution]

I'm not familiar with FDRSOS, but if you boot from a CD, you should be able to access the writeboot utility.

See http://labs.hoffmanlabs.com/node/343 and chapter 4 of the OpenVMS System Manager's Manual at http://h71000.www7.hp.com/doc/82final/aa-pv5mj-tk/aa-pv5mj-tk.html

If you're using a third party product, you need to either make sure you've got a static snapshot of the system disk or be prepared to recover addtional files which may be open for update and possible corruption. Log files, sysuaf.dat and the queue database come immediately to mind.


Andy Bustamante

[Hoff]

How to get to the FC SAN? Booth the CD. Or use a spare disk. Same as when you're installing.

I have no experience with FDRSOS. I am, however, skeptical with anything that tries to snapshot a disk - for all the same reasons that an on-line BACKUP on OpenVMS is such a nasty and intractable problem.

A split-volume shadowset is probably as close as you can get here, if you have a way to quiesce the application activity and flush the host I/O buffers leading up to the split.

I've watched storage engineers repeating the same sorts of mistakes since the 1980s, and the basic mistakes probably weren't new then. After a while, the archival products and product failures in that space start looking like Wyle E Coyote's mail-order ACME archival server.

But again, I haven't worked with the FDRSOS. Maybe the Innovation Data Products folks finally got it right.

[Robert Brooks_1]

After a while, the archival products and product failures in that space start looking like Wyle E Coyote's mail-order ACME archival server.

---

Yeah, something like reinventing the anvil . . .

[cnb]

Hoff> "I've watched storage engineers repeating the same sorts of mistakes since the 1980s, and the basic mistakes probably weren't new then. After a while, the archival products and product failures in that space start looking like Wyle E Coyote's mail-order ACME archival server."

CLASSIC!!!

Just made my morning...thanks!

Rgds,

[Pete Maurer]

Thanks for all the feedback everyone.

Andy, thanks especially for the reference
information on the 'writeboot' utility.

Hoff, FDRSOS is a block level backup solution and I would agree there could be issues with that if the application is not quiesced or if I'm backing up the running
OS.

But I am using EMC's Timefinder to take a
snapshot and backing up the static BCV(business continuance volume).

Thanks again everyone :-)

[Pete Maurer]

See previous reponse. I believe the 'writeboot' utility solves my problem, but I need to test.

Thanks!

[Hoff]

Andy, the http://labs.hoffmanlabs.com/node/343 stuff and getting the boot block out is the easy part of the effort involved with getting a disk copy. (Note too that OpenVMS I64 does not play by the Microsoft-defined rules around the always-changing GUID signatures nor around the particulars of the partitioning rules, too. It's easily possible that a tool that's not tested on OpenVMS I64 can get confused here.)

The boot block stuff doesn't change very often over the life of the system and the disk. And if you do manage to corrupt simple block copy - an error case which is surprisingly typical of various well-known Windows CD recording tools, but I digress - then the chances of a successful full-disk copy are about as likely as catching the Road Runner.

Make no mistake, archival data consistency is a tough problem, and consistency is counter to speed. And the larger your window to changes, the more likely inconsistencies will arise.

Personally, I think looking at the disk is a bad idea, regardless of what the vendor is selling. Too much chaff, too high a risk of inconsistency; outboard archival tools in the OS or (an even harder problem, as there's no view into host and file locking) in the storage controller can't easily synchronize with the applications. I'm typically more interested in the database or in the application; that's where you can get a good and consistent copy of the data.

The footprint in the OP is clearly a corrupt copy of the data, regardless. The whole archive is accordingly suspect. (But on the plus side, you learned about that before you needed the archive.)

And it is SET BOOTBLOCK. Not writeboot.

[Hoff]

> But I am using EMC's Timefinder to take a
snapshot and backing up the static BCV(business continuance volume).

Count me as skeptical. The storage engineers and the marketeers have certainly gotten better at buzz-phrases (BCV, SAN, TimeFinder, etc), and also at obfuscating the numbers of (failed) tries that have been made at this particular problem over the years. Active-passive is hard, and active-active is very hard. (There's a reason why the OpenVMS cluster shared-write implementation is still rather unique, after all, and why OpenVMS itself hasn't gotten an entirely reliable on-line BACKUP.)

[Pete Maurer]

OK, I tested and it just doesn't work. I can't even mount the storage. Back to using
the 'Backup' utility with /image.

Thanks Hoff !