IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size" (761 Views)
Reply
Advisor
Rodney Kimber
Posts: 16
Registered: ‎06-29-2004
Message 1 of 11 (761 Views)
Accepted Solution

IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

When doing a disk image backup to tape and restoring it on another server we seem to end up with a different "Logical Volume Size".   Both servers have identical hardware.

 

Maybe I am doing something wrong or expecting the wrong outcome.

 

We backup the following disk,

Disk SERVER1$DKB1:, device type HP LOGICAL VOLUME, is online, mounted, file-
    oriented device, shareable, available to cluster, error logging is enabled.

    Error count                    0    Operations completed          946206847
    Owner process                 ""    Owner UIC                         [1,4]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count              105    Default buffer size                 512
    Current preferred CPU Id       3    Fastpath                              1
    Total blocks           585871964    Sectors per track                    96
    Total cylinders            63572    Tracks per cylinder                  96
    Logical Volume Size    585871964    Expansion Size Limit          603455488

    Volume label            "VISTA1"    Relative volume number                0
    Cluster size                 128    Transaction count                    99
    Free blocks            522781952    Maximum files allowed           2270821
    Extend quantity              128    Mount count                           1
    Mount status              System    Cache name      "_SERVER1$DKB0:XQPCACHE"
    Extent cache size             64    Maximum blocks in extent cache 52278195
    File ID cache size            64    Blocks in extent cache           132352
    Quota cache size               0    Maximum buffers in FCP cache       5060
    Volume owner UIC           [1,4]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  ODS-5, subject to mount verification, write-back caching
      enabled, special files enabled.


 

Using the following command,

backup/image/ignore=(interlock,label)/label=NOV10 -

      /record/fast/block=30000/list=sys$login:system1.log/noassist -
      DKB1: -
      MKD300:system1.bck/save_set/MEDIA=COMPACT


We restore on the second server using the following command,

backup/log/noassist MKD400:system1.bck/save dkb1:/image

 

 

The disk attributes are then as follows.

Disk SERVER2$DKB1:, device type HP LOGICAL VOLUME, is online, mounted, file-
    oriented device, shareable, available to cluster, error logging is enabled.

    Error count                    0    Operations completed           28619738
    Owner process                 ""    Owner UIC                         [1,4]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count                1    Default buffer size                 512
    Current preferred CPU Id       3    Fastpath                              1
    Total blocks           209712510    Sectors per track                    63
    Total cylinders            13054    Tracks per cylinder                 255
    Logical Volume Size    209712510    Expansion Size Limit          603455488

    Volume label            "VISTA1"    Relative volume number                0
    Cluster size                 128    Transaction count                     1
    Free blocks            147164288    Maximum files allowed           1625678
    Extend quantity              128    Mount count                           1
    Mount status              System    Cache name      "_SERVER2$DKB0:XQPCACHE"
    Extent cache size             64    Maximum blocks in extent cache 14716428
    File ID cache size            64    Blocks in extent cache         14716416
    Quota cache size               0    Maximum buffers in FCP cache       4570
    Volume owner UIC           [1,4]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  ODS-5, subject to mount verification, write-back caching
      enabled, special files enabled.


 

The destination "Logical Volume Size" seems to be set at 99.99 GB whereas the source was 249.27GB.   Sorry,  but I think in GB's not Blocks.  ;-)

 

Any help would be appreciated.

 

Thanks,

Rodney

 

 

 

Honored Contributor
Richard Brodie_1
Posts: 583
Registered: ‎10-09-2003
Message 2 of 11 (755 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

I think your expectation is wrong. "Logical Volume Size" is the same as the "Total Blocks". So nothing funny is happening from that point of view; it's merely that the target volume is smaller than the source.

 

As the device type is 'HP LOGICAL VOLUME', I assume you have some sort of hardware RAID controller installed, and at some point someone has picked 100GB as a round number for the unit size.

 

If you really want to change the size you would have to find out what kind of RAID controller you have and find an online or offline management tool for it. Proceed with extreme caution!


Honored Contributor
Volker Halle
Posts: 5,205
Registered: ‎04-26-2004
Message 3 of 11 (732 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

Rodney,

 

the 'Logical Volume Size' is the size of the volume as currently being useable by the OpenVMS file system. It must be the same size (or smaller) than 'Total blocks' i.e. the size of the physical disk and the 'Expansion Size Limit'.

 

In your case, you've restored your image backup to a disk, which is smaller than your source disk.

 

If your disk is being presented by some kind of RAID controller, you can probably expand the size of the 'physical disk' and then use SET VOL/SIZE to also expand the 'Logical Volume Size' (this functionality is called DVE = Dynamic Volume Expansion) up to the 'Expansion Size Limit'.

 

Volker.

Honored Contributor
Hoff
Posts: 4,948
Registered: ‎01-29-2006
Message 4 of 11 (730 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

Others have answered the base question.  

 

Also ensure that you have some patches for V8.3 loaded, as IIRC there were some DDS/DVE bugs in the base release and particularly around the volume expansion limit.  

 

Booting and using BACKUP from the V8.4 distro is another alternative, if you're backing up a system disk,

 

I'll presume that you know that the backup saveset contents here are suspect and potentially corrupted.

 

Give it a few years; some of us are stuck thinking in TBs and PBs, though still mis-stating capacities as GBs and MBs.  :-)

 

Advisor
Rodney Kimber
Posts: 16
Registered: ‎06-29-2004
Message 5 of 11 (665 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

Thanks everyone.

Both servers are Integrity rx2660 servers. The controller is a P400 controller on both servers.

Richard,  I also forgot to mention that the "Expansion Size Limit" is 603 million blocks whereas the "Logical Volume Size" is hitting a 209 million block limit (99gb).

Volker,  if the "Expansion Size Limit" is the physical size of the disk (603 million blocks) then why is the restored volume being restricted to 209 million blocks instead of the 585 million block "logical volume size" from the source disk?

This is what I am having the greatest difficulty in understanding. See the SERVER2$DKB1: device details above.

I have tried using SET VOL/SIZE and specifying a larger size but I cannot get the "Total Blocks" or "Logical Volume Size" to grow any larger.    When I use SET VOL/LIMIT the expansion size limit actually drops down to a size that is close to the "Logical Volume Size". (ie just above 209 million blocks).

Hoff,  thanks for the concern.  The disk that I am restoring is an application disk and not an operating system disk.   The application is closed down at the time of the backup so that backup is as stable as we can get it.

 

Thanks again.

 

Regards,
Rodney

Honored Contributor
Volker Halle
Posts: 5,205
Registered: ‎04-26-2004
Message 6 of 11 (662 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

Rodney,

 

the size of the physical disk is: Total blocks 209712510

 

That's your problem. Make the disk bigger at the controller level, then use SET VOL/SIZE to increase the 'logical volume size' to the bigger value of 'total blocks'.

 

Volker. 

Honored Contributor
Richard Brodie_1
Posts: 583
Registered: ‎10-09-2003
Message 7 of 11 (655 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

Here's a link to the MSA$UTIL documentation. It might not be installed on 8.3, depending on what updates you have installed.

 

http://h71000.www7.hp.com/doc/83final/ba322_90076/6676pro_006.html

 

'SET CONTROLLER' followed by

'SHOW DISKS' to show the physical volumes and

'SHOW UNITS' to show the logical volumes is a good place to start.

 

 

 

Trusted Contributor
GuentherF
Posts: 236
Registered: ‎10-04-2006
Message 8 of 11 (634 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

BACKUP/IMAGE saves the "Logical Volume Size" and the "Expansion Size Limit" in the save set.

 

On a /IMAGE restore without /NOINIT and no /LIMIT BACKUP sets the "Logical Volume Size" to the current "Total blocks" count of the output disk.

 

Qulifier /LIMIT forces BACKUP to set the  "Logical Volume Size" as stored in the save set.

 

On the other hand "by default" BACKUP uses the "Expansion Size Limit" from the save set. To change this you can use the /LIMIT qualifier.

 

All described under HELP BACKUP.

 

BACKUP by no means can resize the disk device on a /IMAGE restore.

 

/Guenther

Advisor
Rodney Kimber
Posts: 16
Registered: ‎06-29-2004
Message 9 of 11 (633 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

With all of your help,  I now know why.   With the help of the MSA$UTIL utility I now know that the disks aren't actually identical.  The SERVER2 machine atctually has much less disk space than SERVER1.

 

RAID5 has been used on SERVER2 to give the impression that it has the same disk capacity as SERVER1 which uses RAID1.  It looks like a cost cutting excercise has ment that SERVER2 which in this circumsttnace is being used as a disaster recovery machine has ended up with 200GB less disk capacity and this was subtracted from the disk that I have been having capacity issues with in this thread.

 

At least I have now learnt that the "Expansion Size Limit" is not always accurate and that the only way to find out is to do a SET VOL /LIMIT.   If only it did this automatically when I am doing the image restore from tape.

 

Thanks again for all of your help.  This problem has now been resolved.

 

Regards,

Rodney

Honored Contributor
Volker Halle
Posts: 5,205
Registered: ‎04-26-2004
Message 10 of 11 (628 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

re: Guenther

 

<quote>

Qualifier /LIMIT forces BACKUP to set the "Logical Volume Size" as stored in the save set.

</quote>

 

BUT ONLY, if "Total Blocks" of the destination disk is greater than "Logical Volume Size" in the saveset. You cannot increase the "Logical Volume Size" beyond the physical size of the disk.

 

re: Rodney,

 

SHOW DEV/FULL <disk> tells you all you need to know. If "Total blocks" is smaller than you expected, your physical disk is too small. "Expansion Size Limit" is ALWAYS correct, as it is just an attribute of the file system on that disk, which allows you to use the "Dynamic Volume Expansion (DVE") feature of OpenVMS to increase the "Logical Volume Size" of that disk up to the minimum of "Total Blocks" and "Expansion Size Limit" while the system is up and running and the disk is mounted and in use system-wide.

 

Volker. 

Trusted Contributor
GuentherF
Posts: 236
Registered: ‎10-04-2006
Message 11 of 11 (613 Views)

Re: IA64 VMS V8.3 Image Restores from Tape are not using source "Logical Volume Size"

Volker, you've been chasing too many bugs! :-)

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.