- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Standalone Backup on another disk
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2013 07:19 PM
01-02-2013 07:19 PM
Standalone Backup on another disk
Hi,
I'm trying to perform a standalone backup of the system disk. I have created a backup set:
@sys$update:stabackkit $1$dia10:
And the kit successfully runs, putting the files in SYS0. When I try to boot the kit, it fails:
b dia10:
?42 NOSUCHFILE, DIA10
?06 HLT INST
PC = 00000F1D
Bootstrap failure.
However, I can boot the kit from the system disk, with b/e0000000.
What am I missing? Do I need to copy anything else or run WRITEBOOT?
Below are the files that were copied.
Thanks,
-Dan
Directory $1$DIA10:[SYS0]
SYS$LDR.DIR;1 SYSEXE.DIR;1
Total of 2 files.
Directory $1$DIA10:[SYS0.SYS$LDR]
CPULOA.EXE;1 CVDRIVER.EXE;1 CWDRIVER.EXE;1 DBDRIVER.EXE;1
DDDRIVER.EXE;1 DKDRIVER.EXE;1 DLDRIVER.EXE;1 DMDRIVER.EXE;1
DQDRIVER.EXE;1 DRDRIVER.EXE;1 DUDRIVER.EXE;1 DVDRIVER.EXE;1
DYDRIVER.EXE;1 EFDRIVER.EXE;1 EPDRIVER.EXE;1 ERRORLOG.EXE;1
ESDRIVER.EXE;1 ESS$DADDRIVER.EXE;1 ESS$LASTDRIVER.EXE;1
ETDRIVER.EXE;1 EVENT_FLAGS_AND_ASTS.EXE;1 EXCEPTION.EXE;1
EXDRIVER.EXE;1 EXEC_INIT.EXE;1 EZDRIVER.EXE;1 FPEMUL.EXE;1
FXDRIVER.EXE;1 GDDRIVER.EXE;1 IMAGE_MANAGEMENT.EXE;1
IO_ROUTINES.EXE;1 LCDRIVER.EXE;1 LIDRIVER.EXE;1 LOCKING.EXE;1
LOGICAL_NAMES.EXE;1 LPDRIVER.EXE;1 MESSAGE_ROUTINES.EXE;1
MKDRIVER.EXE;1 PADRIVER.EXE;1 PAGE_MANAGEMENT.EXE;1
PBDRIVER.EXE;1 PIDRIVER.EXE;1 PKBDRIVER.EXE;1 PKCDRIVER.EXE;1
PKIDRIVER.EXE;1 PKNDRIVER.EXE;1 PKRDRIVER.EXE;1 PKSDRIVER.EXE;1
PKXDRIVER.EXE;1 PRIMITIVE_IO.EXE;1 PROCESS_MANAGEMENT.EXE;1
PUDRIVER.EXE;1 PWDRIVER.EXE;1 SECURITY.EXE;1 SYS$SCS.EXE;1
SYS.EXE;1 SYSDEVICE.EXE;1 SYSGETSYI.EXE;1 SYSLICENSE.EXE;1
SYSLOA1202.EXE;1 SYSLOA1302.EXE;1 SYSLOA1303.EXE;1 SYSLOA1701.EXE;1
SYSLOA410.EXE;1 SYSLOA41D.EXE;1 SYSLOA41W.EXE;1 SYSLOA420.EXE;1
SYSLOA42D.EXE;1 SYSLOA42S.EXE;1 SYSLOA42W.EXE;1 SYSLOA43.EXE;1
SYSLOA43D.EXE;1 SYSLOA43S.EXE;1 SYSLOA43W.EXE;1 SYSLOA440.EXE;1
SYSLOA46.EXE;1 SYSLOA49.EXE;1 SYSLOA520.EXE;1 SYSLOA60.EXE;1
SYSLOA600.EXE;1 SYSLOA640.EXE;1 SYSLOA64D.EXE;1 SYSLOA650.EXE;1
SYSLOA65D.EXE;1 SYSLOA660.EXE;1 SYSLOA66D.EXE;1 SYSLOA670.EXE;1
SYSLOA67D.EXE;1 SYSLOA690.EXE;1 SYSLOA69D.EXE;1 SYSLOA700.EXE;1
SYSLOA70D.EXE;1 SYSLOA730.EXE;1 SYSLOA750.EXE;1 SYSLOA780.EXE;1
SYSLOA790.EXE;1 SYSLOA8NN.EXE;1 SYSLOA8PS.EXE;1 SYSLOA8SS.EXE;1
SYSLOA9AQ.EXE;1 SYSLOA9CC.EXE;1 SYSLOA9RR.EXE;1 SYSLOAUV1.EXE;1
SYSLOAUV2.EXE;1 SYSLOAWS1.EXE;1 SYSLOAWS2.EXE;1 SYSLOAWSD.EXE;1
SYSTEM_DEBUG.EXE;1 SYSTEM_PRIMITIVES.EXE;1
SYSTEM_PRIMITIVES_MIN.EXE;1 SYSTEM_SYNCHRONIZATION_UNI.EXE;1
TFDRIVER.EXE;1 TMDRIVER.EXE;1 TSDRIVER.EXE;1 TTDRIVER.EXE;1
TUDRIVER.EXE;1 TVDRIVER.EXE;1 VAXEMUL.EXE;1
WORKING_SET_MANAGEMENT.EXE;1 XQDRIVER.EXE;1
Total of 119 files.
Directory $1$DIA10:[SYS0.SYSEXE]
ISL_LVAX_062.SYS;1 ISL_SVAX_062.SYS;1 PAGEFILE1.SYS;1 STANDALON.EXE;1
STANDCONF.EXE;1 SYSBOOT.EXE;3 SYSINIT.EXE;1 VAXVMSSYS.PAR;1
VMB.EXE;1
Total of 9 files.
Grand total of 3 directories, 130 files.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2013 09:02 PM
01-02-2013 09:02 PM
Re: Standalone Backup on another disk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-02-2013 09:13 PM
01-02-2013 09:13 PM
Re: Standalone Backup on another disk
Dan, you're really OK booting Standalone from the system disk to both save and restore. Most of the system image gets loaded into memory and the system is very, very minimal. It shouldn't be a problem even if you're compressing the system disk. But, to be safe, it certainly can't hurt to boot from an alternate disk.
But your problem seems possible that you may not have a bootblock on $1$DIA10. Your root is SYS0 on DIA10 where the bootable Standalone on the system disk is SYSE. None of my VMS systems are booted right now so this is from memory. I think you'll need to use, again I THINK, WRITEBOOT to write the bootblock on DIA10. There are examples in some of the command procedures on the system disk and I thought that STABACKIT would have written a bootblock as part of it's procedure. You might search for "WRITEBOOT" in command procedures on the system disk to find the syntax. I'm also guessing that you're NOT running a mixed VAX and Alpha cluster with DSSI as your shared interconnect so you don't have any problems trying to write a VAX bootblock from an Alpha, are you? If so there is a way to get this working but I'll have to research it to refresh those brain cells.
You should also check to make sure that there's a [SYSEXE] directory on DIA10 and that there are files in there, most importantly VMB.EXE. What type VAX are you booting and have you checked the console setting for BFLG (some really old VAX models may not use BFLG so FYI) to see where that points? Have you tried to boot using the console command:
b/00000000 dia10
or
b/r5:0 dia10
?
An even more rudimentary question? Is this on a "real" VAX or one of the emulated hardware models running virtually?
Sorry for all the questions...
bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2013 07:51 AM
01-03-2013 07:51 AM
Re: Standalone Backup on another disk
The details of how the primary bootstrap works differ a lot from machine to machine but I would have thought it was a ROM based VMB.EXE, so I would be looking for something odd with SYSBOOT.EXE or its directory path rather than a bootblock.
Have a double check with /FI and or /SIZ to make sure that you haven't got directory entries that point nowhere. See if ANALYZE/DISK shows something odd with the target volume.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2013 09:18 AM
01-03-2013 09:18 AM
Re: Standalone Backup on another disk
There were only three command procedures on my VAX V7.3 system disk that executed WRITEBOOT, STABACKIT, CONSCOPY and VMSKITBLD. For what it's worth, WRITEBOOT execution goes like this (for Dan's Standalone disk):
$ run sys$system:writeboot
Target system device (and boot file if not VMB.EXE): $1$DIA10:[SYS0.SYSEXE]VMB.EXE
Enter VBN of boot file code (default is 1) : 1
Enter load address of primary bootstrap in HEX (default is 200): 200
I'll admit that I haven't dug into VAX STABACKIT in many years but do recall that not always does the bootblock get written on an alternate device. It would also be entertaining to know what type disk is $1$DIA10 (is it an RF disk with a dedicated ISE or is it a SCSI disk behind a HSD) and how is that disk initialized?
Another "just FYI," this is the result I got when I tried to boot my MV3100 "server" from a non-existing root:
>>> b/r5:40000000 dkb0
-DKB0
?42 NOSUCHFILE
?06 HLT INST
PC = 00000C66
Not exact (this system is SCSI only) but close. My guess would be a VAX4000-1xx or one of the larger Q-Bus machines and the setting for BFLG may be wrong? Still waiting for Dan to respond with more details.
bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2013 10:52 AM
01-03-2013 10:52 AM
Re: Standalone Backup on another disk
Steven Schweda:
bflag depends on node, but they're what you'd normally expect-
node 1: 0
node 2: 10000000
node 3: 20000000
device is DIA0 for nodes 1 and 2, and DIA0 for node 3 (same disk, but alternate DSSI bus).
The output is pretty much complete. I can't capture the bootup sequence except to printer, so I'm retyping it. The only thing I didn't include was the initial start.
(BOOT/R5:0 DIA10)
2..
-DISK10$DIA10
Bob Blunt:
Thanks. I was trying to get the kit working on another drive so I'd have a chance to restore it should the SYSTEM disk die. I have an 8mm and 9-track I could use for the kit but they're a bit slow.
The cluster is all VAX 4000-600, so no Alphas (and yes, physical nodes). Sorry, I had that in my original post but it got eaten when I had to log in and I guess I forgot to re-type that. I think VMB.EXE is in the firmware on the 4000, but it is also in SYSEXE.
Richard Brodie_1:
The disk checks out fine. I also tried to build a kit on a different volume (DIA6) just in case the size matters, but I got the same errors. DIA10 is an RF73 but DIA6 is an RF35.
Bob Blunt (#2):
Should I try writeboot? I wasn't sure if that was needed on the 4000, so I didn't want to shotgun it, especially since it's a production system. :)
The disks are RF35 or RF73 and were initialized with /owner=system/extens=100/nohighwater/headers=2500.
Thanks, guys, for your help.
-Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2013 11:01 AM
01-03-2013 11:01 AM
Re: Standalone Backup on another disk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2013 11:13 AM
01-03-2013 11:13 AM
Re: Standalone Backup on another disk
Thanks again for your help.
-Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-03-2013 03:17 PM
01-03-2013 03:17 PM
Re: Standalone Backup on another disk
Dan, rewriting (or writing) the bootblock for the alternate disk won't hurt anything but it seems like you're past the problem now with the rebuild. To be 'safe' when you boot your alternate disk S/A use:
b/r5:00000000 DIA10 (or DIB10 depending on what node)
That way you'll know for sure you're selecting the right root for your alternate standalone (unless booting from the system disk, of course).
Wow, REAL RF disks and a three-node DSSI cluster on top of that. AND a 9-track tape, too! I bet getting maintenance and spares is quite entertaining.
bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-04-2013 11:22 AM
01-04-2013 11:22 AM
Re: Standalone Backup on another disk
Bob, thanks for the tips and confirming writing the bootblock won't hurt.
Yeah, getting spares can be a challenge. I have 3-4 spare RF35s from a drive cabinet we took out when I added the third node and we still maintain a maintenance contract for failures, which there seems to be about once a year (mainly with the 8mm exabyte drive). I've thought about virtualizing since these disks are getting pretty old and this system doesn't have the usage it once had, but it's so reliable (though backups take all night). I was hired just out of high school to help set this system up, and now I'm training our new guys how to manage a system that's now 21 years old. :)
-Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-05-2013 05:51 AM
01-05-2013 05:51 AM
Re: Standalone Backup on another disk
>though backups take all night
I'll bet they do.
Virtualization would help a lot there too. Use a virtual tape drive that writes "tapes" (container files actually) out on your corporate SAN (or a local Windows/Linux drive). Then let the enterprise backup tool come along and backup those "tapes" in accordance with the enterprise policies. Gets you out of the tape handling business completely. You still use the same VMS backup tools and procedures that you use today. Recovery is as simple as asking the enterprise folks to restore your "tape" file, and then mount it in VMS (just as you would any tape) and restore.
Virtualization isn't cheap, but I can't believe those maintenance contracts are cheap either. If you haven't had some serious discussions with a vendor about virtualizing those systems, lately, you should.
Full Disclosure: We sell CHARON VAX emulation solutions.
Brad McCusker
Software Concepts International
Software Concepts International