Bound Volume Sets (BVS) and backups

[Rick Dyson]

BVS are new to me. Never used them myself, had heard of them only. today, I was presented with a customer with a 2 disk BVS (RZ29B disks, I believe) where one is experiencing a lot of errors and the rate is increasing. They seem to be recoverable so far...

What is the proper way to backup the data (Oracle data files that are big) to tape and be able to restore to new hardware assuming it is replaced?

BVS = Stooge consisting of Larry Shemp.

$ Mount/System/Bind=STOOGE PMSYS$DKC300:,PMSYS$DKD300: LARRY,SHEMP

Should I use something like (minimal for clarity):

$ Backup /image disk$stooge mka0:stooge.bck

I normally use a device name for the source, but there does not appear to be one for a BVS.
(I am a HBVS guy, this BVS stuff is too old for me. :)

rick

[Uwe Zessin · Accepted solution]

Use the root volume (first one) as input for BACKUP. As been working for me in VAX/VMS V4.x ;-)

[Rick Dyson]

Uwe,

If I understand correctly, I should use this backup command:

$ Backup /Image pmsys$dkc300: mka0:stooge.bck

The "root" being the first ordered list device on the mount command, right?

[Karl Rohwedder]

Rick,

I think DISK$STOOGE should work also.

A SHOW DEV /FU shows the relative number of every disk in a volume set.

regards Kalle

[Uwe Zessin]

Yes, that's how I did it when I was managing a system with multivolume sets (aka BVS).

[Uwe Zessin]

Well, what is the output of

$ show logical DISK$STOOGE

?? (not a rethorical question - it's too long since I dealt with them)

[Rick Dyson]

$ Show Logical Disk$Stooge
"DISK$STOOGE" = "PMSYS$DKC300:" (LNM$SYSTEM_TABLE)

So I agree, it should work as either Disk$Stooge or PMSYS$DKC300.

Just for completeness, what about a backup saveset that was created by an image backup of the "RVN 2" disk? I have

Backup/Image pmsys$dkd300: mka0:larry.bck

Do anyone think that would have worked OK or will it miss stuff from the RVN 1 disk's index file, etc.?

If I (for example) then later use:

$ Backup /Image MKA0:Larry.bck $1$DKA0:

onto another system, would it restore all the contents correctly of the former Disk$Stooge?

Rick
rick

[Uwe Zessin]

There is a BACKUP/VOLUME=rvn qualifier, but the root volume is essential for the operation of the set.

[Ian Miller.]

directories are often only on the first volume in the set with files on both so you need both disks backed up as described.

[Rick Dyson]

I have some deeper problems with this set, it turns out. Any help will be appreciated!

When I backed up as "Disk$Stooge" it seemed to be able to get to files that I can not get to from "stooge" but can from Shemp... I suspect something is corrupt.

...snip...
%BACKUP-S-COPIED, copied PMSYS$DKC300:[ORACLE.CMDLAS]041.LIS;1
%BACKUP-S-COMPARED, compared PMSYS$DKC300:[ORACLE.CMDLAS]041.LIS;1
...snip...

Even though backup of Disk$Stooge seemed to find the problem area, I can't access it manually:

$ dir PMSYS$DKC300:[ORACLE.CMDLAS]041.LIS;1
%DIRECT-E-OPENIN, error opening PMSYS$DKC300:[ORACLE.CMDLAS]041.LIS;1 as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

What happens if a user works directly on a disk that is a member of the BVS, but does not use the BVS name? E.g.,

$ Copy junk.dat disk$shemp:[oracle.cmdlas]

(Larry and Shemp are members of the BVS Stooge.)

Should I then be able to see the following?

$ Dir Disk$Stooge:[oracle.cmdlas]junk.dat

I sort of think this is doing a backdoor operation on a member without the master knowing about it. Does anyone else agree?

I did run Analayze/Disk/Repair on Disk$Stooge, Disk$Larry, & Disk$Shemp. Even if it would have broken everything, I was counting on the backup. It did not find much besides a miscount on block ownership, though that could have been due to this one user who has an entire couple directories on Shemp. Maybe it was now updating it in the diskquota.

BTW, I tried every thing I could think of to "Backup" those directories to another, single, flat disk I have. Backup refused to acknowledge their existence. I ended up using Copy for each directory, one at a time.

But, I explicitly see the directory and files in the log file (and verify) from the big backup I did yesterday of Disk$Stooge!?! It seemed to be able to walk down the tree even though I can't see it from Stooge!

$ dir disk$stooge:[oracle]*.dir
%DIRECT-W-NOFILES, no files found
$ show log disk$stooge
"DISK$STOOGE" = "PMSYS$DKC300:" (LNM$SYSTEM_TABLE)
$ sho log disk$shemp
"DISK$SHEMP" = "PMSYS$DKD300:" (LNM$SYSTEM_TABLE)
$ dir disk$shemp:[oracle]*.dir

Directory DISK$SHEMP:[ORACLE]

CMDLAS.DIR;1

Total of 1 file.

Rick

[Ian Miller.]

can you do a DIR/FULL on that directory. I wonder which volume its on. Try also
$ DFU VERIFY/DIR/LOCK
http://h71000.www7.hp.com/freeware/freeware70/dfu/

to see if it finds anything

[Rick Dyson]

The only way I can see the directory and it's contents is if I use Disk$Shemp or the explicit device name, DKD300. A dir of Disk$Stooge says no such file. But a backup of Disk$Stooge reported it was there...

I am a little concerned that the backup might not be good, even though it passed a verify.

I'm also starting to suspect that the 150+ disk errors we have gotten recently are due to this messed up BVS structure and not real H/W errors. The errors were translated to say things like "track following error" and "recovered error".

I attached a bunch of output from the specifics of these disks that might help shed some light.

rick


rick

[Rick Dyson]

Of course, I guess I should actually attach the file...

rick

[Uwe Zessin]

Strange, that sounds like you did not bind an *empty* volume (SHEMP) to the root (LARRY).

[Rick Dyson]

Uwe,

Maybe that is what happened. This v7.1 system has been running for years. It is on an old Alpha4000 and I was not around for it's beginnings. I manage the newer ES40 @ v7.3.

Though, the one directory that is the troublemaker has been undergoing recent activity and changes.

rick