Alpha 8.3 BACKUP and bound volumes, size reporting

Alpha VMS 8.3 $ backup/list=disk2.list/image/ignore=(nobackup,interlock)/noalias $disk2: $disk 4:[000000]disk2.save/save %BACKUP-E-BADDIR, directory $DISK2:[APPLICATIONS.KERMIT] has invalid format %BACKUP-E-BADDIR, directory $DISK2:[APPLICATIONS.MOSAIC41] has invalid format BIKE::_FTA17: 06:32:28 BACKUP CPU=00:01:51.43 PF=6943 IO=205964 MEM=1049 Last file scanned: $DISK2:[CMUIP066]CMUIP066.B;1 Saveset volume:1, saveset block:12122 (32256 byte blocks) 372.89MB saved out of 1.43GB, 25% completed Save rate: 496KB/sec, estimated completion time: 07:10:12.80 %BACKUP-E-BADDIR, directory $DISK2:[KITS.TEMP.DECW$DEFAULTS] has invalid format The bound volume set is 4 DSSI drives of 2 gigs. They are corrupt. QUESTION: The new 8.3 displays at <ctrl-T> are very nice. But I need to know if the 1.43gig being reported is just for the current physical drive, or if this would be for the whole volume set. If it is the whole volume set, this backup is a waste of time since there should be nearly 5-6 gigs of data. These disks are reported as 1.86 gigs big. Based on SHOW DEV/FULL and adding each of the drive's free block counts: The whole volume should have 5.9 gigs of data to backup, not the 1.43gb reported by BAckup. Is this a quirk of Backup's reporting ? Or is it because Backup really is only seeing 1.43 gigs of used data on the drive ? (with over 4 gigs lost ?) So the volume should have at least 5.9 gigs to backup, not the 1.43 Backup reports.

Update: BACKUP now has been reporting 100% completion of 1.43 gigs saved of 1.43 gigs, but is continuing to grow the number of saveset blocks and seems to continue to process files. With a /IMAGE backup, is there any order in which BACKUP processes the files with regards to positioning on which physical drive ? AKA: would a relatively small number of errors (only 3 corrupt directories in the first 1.43 gigs) reflect processing over 4 physical drives ? Or would it be because it has only processed files residing on RVN 0 and the bad news are yet to come when it hits the RVN that is totally corrupt ? (This is being written fropm my MAC because Mozilla has become unable to display posts on the alpha anymore)

OK, the backup has completed. Alpha VMS 8.3 , doing a BACKUP/IMAGE/IGNORE=(nobackup,interlock)/NOALIAS of a bound volume set (ODS2). Pressing <ctrl-t> does produce the nice output of the current status. However: The estimated total size to backup covers only the first physical volume of the bound set. And the expected completion time is based only on that device's size. Once it has backed up the originally expected amount, BACKUP continues to huff and puff. However, <ctrl-T> reveals that it is 100% complete, and reports it has backed up 1.43gigs of 1.43 gigs (for instance). The number of blocks written to the saveset does increase. I was expecting it to at least say "backed up 3.5 gigs of 1.43 gigs, or 200%" (aka: that the counter of how much it has backed up would continue to increase despite the original estimate of total size being off). (this is for an interactiove backup sending the output to a disk based save set.)

Given your predicament, I don't think that you can really take anything for granted - you've had four disks in a bound volume set which appear to have become corrupt, you've got backup reading a corrupt data structure on disk into a saveset. I suspect the fundamental error wasn't VMS 7.3 on VAX but using bound volume sets in the first place. That doesn't do you much good now though... Steve JF Mezei wrote: > OK, the backup has completed. > > Alpha VMS 8.3 , doing a BACKUP/IMAGE/IGNORE=(nobackup,interlock)/NOALIAS > of a bound volume set (ODS2). > > Pressing <ctrl-t> does produce the nice output of the current status. > > However: > > The estimated total size to backup covers only the first physical volume > of the bound set. And the expected completion time is based only on that > device's size. > > Once it has backed up the originally expected amount, BACKUP continues > to huff and puff. However, <ctrl-T> reveals that it is 100% complete, > and reports it has backed up 1.43gigs of 1.43 gigs (for instance). The > number of blocks written to the saveset does increase. > > I was expecting it to at least say "backed up 3.5 gigs of 1.43 gigs, or > 200%" (aka: that the counter of how much it has backed up would > continue to increase despite the original estimate of total size being off). > > > (this is for an interactiove backup sending the output to a disk based > save set.)

etmsreec@yahoo.co.uk wrote: > [...snip...] > > I suspect the fundamental error wasn't VMS 7.3 on VAX but using bound > volume sets in the first place. That doesn't do you much good now > though... Steve, oh Steve ... how is using volume sets a "fundamental error"? This is how myths propagate. I've been using volume sets for close to 25 years now, and I've never been bitten by anything like this. Signed, Miffed of Tunbridge Wells.

etmsreec@yahoo.co.uk wrote: > > Given your predicament, I don't think that you can really take anything > for granted - you've had four disks in a bound volume set which appear > to have become corrupt, you've got backup reading a corrupt data > structure on disk into a saveset. Well, the overall disk structure is "sane" except for a whole bunch of blocks incorrectly markled as free and a number of files no longer accessible because their directory file were ocverwritten with stuff. However, one would expect BACKUP's, status displays to at least match those of SHOW DEVICE/FULL. If show device still shows a bound volume set constiting of 4 disks of 1.85 gigs each, and a certain number of free blocks, then Backup's calculations should have matched the numbers as a whole, instead of only matching the numbers of the first volume.

Roy Omond wrote: > etmsreec@yahoo.co.uk wrote: > >> [...snip...] >> >> I suspect the fundamental error wasn't VMS 7.3 on VAX but using bound >> volume sets in the first place. That doesn't do you much good now >> though... > > > Steve, oh Steve ... > > how is using volume sets a "fundamental error"? This is how myths > propagate. I've been using volume sets for close to 25 years now, > and I've never been bitten by anything like this. > > Signed, > > Miffed of Tunbridge Wells. I was taught, in the System Management Course, ca. 1984, that bound volume sets were risky and should be avoided if at all possible. In particular, if you lose one drive in the bound set, the volume set is toast! I've since used bound volume sets when I absolutely have to but I avoid them whenever possible. It's not a "fundamental error" but it's not a good idea either if there is any other choice.

Maybe fundamental was a poor choice of word, but given that JF complained on another thread that his problems were due to his upgrade to 7.3 it's not *that* poor. My take, overall, on bound volume sets is similar to that of Richard G. - use them if you have to but they're risky things in some situations. If one spindle goes, the volume is toast. Their design, I would guess, dates back to when disk storage was expensive. These days, storage is cheap. Steve Roy Omond wrote: > etmsreec@yahoo.co.uk wrote: > > [...snip...] > > > > I suspect the fundamental error wasn't VMS 7.3 on VAX but using bound > > volume sets in the first place. That doesn't do you much good now > > though... > > Steve, oh Steve ... > > how is using volume sets a "fundamental error"? This is how myths > propagate. I've been using volume sets for close to 25 years now, > and I've never been bitten by anything like this. > > Signed, > > Miffed of Tunbridge Wells.

etmsreec@yahoo.co.uk wrote: > Maybe fundamental was a poor choice of word, but given that JF > complained on another thread that his problems were due to his upgrade > to 7.3 it's not *that* poor. > > My take, overall, on bound volume sets is similar to that of Richard G. > - use them if you have to but they're risky things in some situations. > If one spindle goes, the volume is toast. Their design, I would guess, > dates back to when disk storage was expensive. These days, storage is > cheap. > <snip> I think that cost of the disk was not so much a factor as the size of disks!!! I came on board in 1984 when an RA81 with, IIRC, 456MB was a huge disk! It was also expensive; again IIRC it had a $25,000 price tag and that MAY have been AFTER educational discount!!!!! The earlier drives (washing machine style RPxx or RMxx) were physically bigger but had even less capacity. A bound volume set may be justified if you have a file that is larger than what a single drive will hold. My first choice in such a case would be a bigger disk or a RAID-5 set. I'd go to a bound volume set if neither option was available.

"Richard B. Gilbert" wrote: > A bound volume set may be justified if you have a file that is larger > than what a single drive will hold. My first choice in such a case > would be a bigger disk or a RAID-5 set. I'd go to a bound volume set if > neither option was available. In my case, it was to have been a temporary situation when upgrading from my SCSI microvax II to the DSSI 400-600. The DSSI disks I had were relatively small compared to the big disk I had on my MVII (10 gigs), so it was simpler to simply create a bound volume set to appear as a single disk, thus greatly simplifying the move. I also had hopes of bveing able to easily put my SCSI drives into the DSSI cabinet since they are supposed to be able to handle it. But I got no luck on it. And within a month, I expect to go back to SCSI drives, but this time on a second alpha.