FS
Documentation

Backup3G/COSstacker 2.1.2 Release Notes

From Documentation

(Difference between revisions)
Jump to: navigation, search
Revision as of 03:32, 6 September 2007
Moff (Talk | contribs)

← Previous diff
Revision as of 00:34, 7 September 2007
Moff (Talk | contribs)
(Notes on Configuring Stacker 2.1.2)
Next diff →
Line 99: Line 99:
COSbackup must be installed prior to installing Stacker 2.1.2. COSbackup must be installed prior to installing Stacker 2.1.2.
 +
To install the stacker routines for use by COSbackup, install Stacker as a module using {{cnav|Application > Install}} under the {{cnav|Config > COSMOS Configuration > COSMOS applications}} menu option. To install the stacker routines for use by COSbackup, install Stacker as a module using {{cnav|Application > Install}} under the {{cnav|Config > COSMOS Configuration > COSMOS applications}} menu option.
 +
See the COSMOS user guide for details of how to install COSmanager applications. See the COSMOS user guide for details of how to install COSmanager applications.
 +
After the installation is complete, you must setup COSbackup to support your stacker. Most of the After the installation is complete, you must setup COSbackup to support your stacker. Most of the
setup should be done in the {{cnav|Config > COSbackup configuration > Maintain drives and stackers}} option. You can manage media in your stacker by using the Stacker management option (or Stacker button). setup should be done in the {{cnav|Config > COSbackup configuration > Maintain drives and stackers}} option. You can manage media in your stacker by using the Stacker management option (or Stacker button).
Line 107: Line 110:
==== Configuring Load Operations ==== ==== Configuring Load Operations ====
-loadstkr and unloadstkr are two small shell scripts that call the Stacker driver,+<tt>loadstkr</tt> and <tt>unloadstkr</tt> are two small shell scripts that call the Stacker driver, <tt>stkrctrl(1)</tt>. They are used in the ‘Load_op’ and ‘Unload_op’ of the ‘loadop’ table. For
-stkrctrl(1). They are used in the ‘Load_op’ and ‘Unload_op’ of the ‘loadop’ table. For+
example: example:
-Loading class stkrctrl_1+ 
-Description Random access stacker using STKRSTRL(1)+:{|
-Auto loading? yes+! align="left" width="150" | Loading class
-Load cmd loadstkr $load_device $Device_nr $Slot $Load_posn+| stkrctrl_1
-Load next cmd [ Only used for sequential (dumb) stackers ]+|-
-Unload cmd unloadstkr $load_device $Device_nr $Slot $Load_posn+! align="left" width="140" | Description
-Note APPL_DB is no longer used by the DB tools so is not needed by the current COSMOS+| Random access stacker using STKRSTRL(1)
-applications. However COS/Manager still uses it, so it should still be set to+|-
-$APPL_HOME/db.+! align="left" width="140" | Auto loading?
-If you choose to use another vendor-supplied stacker driver program, then the appropriate calls to+| yes
-that program must be put into the ‘Load_op’ and ‘Unload_op’ fields.+|-
-Release Notes for Stacker 2.1.2 (upgrade from stacker 2.1 or 2.1.1)—January 2000 Page 4+! align="left" width="140" | Load cmd
-get_bcode, ie_load and ie_unload are three shell scripts that call the Stacker inventory+| loadstkr $load_device $Device_nr $Slot $Load_posn
-driver, stkrinv(1), for use in the ‘Extended Stacker Operations’ of the ‘loadop’ table. For+|-
-loading class stkrctrl_4 (Tape silo with barcode & multiple I/E slots) the row should be like:+! align="left" width="140" | Load next cmd
-Scan slot cmd get_bcode $Load_device $Slot+| [ Only used for sequential (dumb) stackers ]
-Scan drive cmd get_bcode $Load_device $Load_posn+|-
-Allocate cmd ie_load -t 60 $Load_device $Slot+! align="left" width="140" | Unload cmd
-Deallocate cmd ie_unload -t 60 $Load_device $Slot+| unloadstkr $load_device $Device_nr $Slot $Load_posn
 +|}
 + 
 +:{{Note|APPL_DB is no longer used by the DB tools so is not needed by the current COSMOS applications. However COSmanager still uses it, so it should still be set to $APPL_HOME/db.}}
 + 
 +If you choose to use another vendor-supplied stacker driver program, then the appropriate calls to that program must be put into the ‘Load_op’ and ‘Unload_op’ fields.
 + 
 +<tt>get_bcode</tt>, <tt>ie_load</tt> and <tt>ie_unload</tt> are three shell scripts that call the Stacker inventory driver, <tt>stkrinv(1)</tt>, for use in the ‘Extended Stacker Operations’ of the ‘loadop’ table. For loading class <tt>stkrctrl_4</tt> (Tape silo with barcode & multiple I/E slots) the row should be like:
 + 
 +COSbackup must be installed prior to installing Stacker 2.1.2.
 + 
 +To install the stacker routines for use by COSbackup, install Stacker as a module using {{cnav|Application > Install}} under the {{cnav|Config > COSMOS Configuration > COSMOS applications}} menu option.
 + 
 +See the COSMOS user guide for details of how to install COSmanager applications.
 + 
 +After the installation is complete, you must setup COSbackup to support your stacker. Most of the
 +setup should be done in the {{cnav|Config > COSbackup configuration > Maintain drives and stackers}} option. You can manage media in your stacker by using the Stacker management option (or Stacker button).
 + 
 +<br>
 +==== Configuring Load Operations ====
 + 
 +<tt>loadstkr</tt> and <tt>unloadstkr</tt> are two small shell scripts that call the Stacker driver, <tt>stkrctrl(1)</tt>. They are used in the ‘Load_op’ and ‘Unload_op’ of the ‘loadop’ table. For
 +example:
 + 
 +:{|
 +! align="left" width="150" | Scan slot cmd
 +| get_bcode $Load_device $Slot
 +|-
 +! Salign="left" width="150" | Scan drive cmd
 +| get_bcode $Load_device $Load_posn
 +|-
 +! align="left" width="150" | Allocate cmd
 +| ie_load -t 60 $Load_device $Slot
 +|-
 +! align="left" width="150" | Deallocate cmd
 +| ie_unload -t 60 $Load_device $Slot
 +|}
 + 
The get_bcode script is used to scan the barcode labels on the media in the slots and drives. You The get_bcode script is used to scan the barcode labels on the media in the slots and drives. You
can modify this script to map any alpha component of the barcode label. The default mapping is to can modify this script to map any alpha component of the barcode label. The default mapping is to

Revision as of 00:34, 7 September 2007

(upgrade from stacker 2.1 or 2.1.1)

Contents

Overview and Features

COSstacker

This patch (which is re-defined to a new release of a module) fixes issues missed during the development of Stacker 2.1 and from media misload related problems. Please refer attached table for full information. The distribution is platform specific. It will run on most UNIX platforms supported by COSbackup 3.2.1 (or newer).


New features in COSstacker


Environment

Software Prerequisites

Before you can install Stacker 2.1.2, COSMOS 3.2.1 (or newer) and COSbackup 3.2.1 (or newer) must already be installed on the same host.

Stacker is a licence product. It requires a valid COSbackup (BKP) licence key.


Disk Space Required

Stacker 2.1.2 is installed under the COSbackup home directory. It requires approximately 200 Kbytes disk space.


Supported Platforms

Stacker 2.1.2 will run on most UNIX platforms supported by COSbackup. For other platforms, including Windows/NT/2000, sequential media loading only is supported.


Supported Devices

Stacker 2.1.2 will operate with all stacker devices that conform to at least the standard SCSI 2 command set for such devices.


Operating System Level of Support
AIX 4.1 Full control via Functional Software supplied kernel driver
Digital UNIX 4 Full control via OS passthru driver
HP/UX 10 and 11 Full control via OS passthru driver
Linux Intel 2.2 and 2.4 kernel Full control via OS passthru driver
NCR UNIX 3 Full control via OS passthru driver
DC/OSx 1.1 Sequntial access only
Dynix/ptx 4 Full control via OS passthru driver
SGI IRIX 6 Full control via OS passthru driver
Solaris 2 Intel Sequntial access only
Solaris 2 Sparc Full control via Functional Software supplied kernel driver
Windows/NT/2000 Sequntial access only


Known vendors Stacker 2.1.2 is confirmed to operate with include Storage Tek, Overland, SUN, HP, IBM, ADIC, Exabyte, Breece Hill and Quantum.


Terminology

Stacker makes reference to terminology used throughout the industry, which in some cases nay be confusing:


Notes on Configuring Stacker 2.1.2

COSbackup must be installed prior to installing Stacker 2.1.2.

To install the stacker routines for use by COSbackup, install Stacker as a module using Application > Install under the Config > COSMOS Configuration > COSMOS applications menu option.

See the COSMOS user guide for details of how to install COSmanager applications.

After the installation is complete, you must setup COSbackup to support your stacker. Most of the setup should be done in the Config > COSbackup configuration > Maintain drives and stackers option. You can manage media in your stacker by using the Stacker management option (or Stacker button).


Configuring Load Operations

loadstkr and unloadstkr are two small shell scripts that call the Stacker driver, stkrctrl(1). They are used in the ‘Load_op’ and ‘Unload_op’ of the ‘loadop’ table. For example:

Loading class stkrctrl_1
Description Random access stacker using STKRSTRL(1)
Auto loading? yes
Load cmd loadstkr $load_device $Device_nr $Slot $Load_posn
Load next cmd [ Only used for sequential (dumb) stackers ]
Unload cmd unloadstkr $load_device $Device_nr $Slot $Load_posn
Note
Note
APPL_DB is no longer used by the DB tools so is not needed by the current COSMOS applications. However COSmanager still uses it, so it should still be set to $APPL_HOME/db.

If you choose to use another vendor-supplied stacker driver program, then the appropriate calls to that program must be put into the ‘Load_op’ and ‘Unload_op’ fields.

get_bcode, ie_load and ie_unload are three shell scripts that call the Stacker inventory driver, stkrinv(1), for use in the ‘Extended Stacker Operations’ of the ‘loadop’ table. For loading class stkrctrl_4 (Tape silo with barcode & multiple I/E slots) the row should be like:

COSbackup must be installed prior to installing Stacker 2.1.2.

To install the stacker routines for use by COSbackup, install Stacker as a module using Application > Install under the Config > COSMOS Configuration > COSMOS applications menu option.

See the COSMOS user guide for details of how to install COSmanager applications.

After the installation is complete, you must setup COSbackup to support your stacker. Most of the setup should be done in the Config > COSbackup configuration > Maintain drives and stackers option. You can manage media in your stacker by using the Stacker management option (or Stacker button).


Configuring Load Operations

loadstkr and unloadstkr are two small shell scripts that call the Stacker driver, stkrctrl(1). They are used in the ‘Load_op’ and ‘Unload_op’ of the ‘loadop’ table. For example:

Scan slot cmd get_bcode $Load_device $Slot
Scan drive cmd get_bcode $Load_device $Load_posn
Allocate cmd ie_load -t 60 $Load_device $Slot
Deallocate cmd ie_unload -t 60 $Load_device $Slot

The get_bcode script is used to scan the barcode labels on the media in the slots and drives. You can modify this script to map any alpha component of the barcode label. The default mapping is to ignore any alpha characters. The ie_load and ie_unload scripts are used to allocate and deallocate media via import/ export or letterbox slots. The -t flag specifies a timeout value in seconds. If you do not insert a media for allocate or extract a media for deallocate within the time the the action will timeout. You can change the timeout value here if a different length of time is needed. The default value is 60 seconds. Configuring Stackers For each stacker you must create an entry in the ‘stacker’ table. For example: Stacker ADIC-DLT7000 Description ADIC VLS DLT7000 Slots 7 Import/export slots[ leave NULL if your stacker doesn’t support these ] Operations class stkrctrl_1 Host gomez Device /dev/stkr4 Media type DLT-70 Configuring Drives in a Stacker Define the tape drive(s) in the stacker. The ‘Loading location’ should be the name of the stacker (ADIC-DLT7000 in the above example). If the stacker has more than one drive, you need to specify the ‘Drive position’ for each, number consecutively from 1. Before running a backup, you must allocate scratch tapes to the stacker (that is, load some into the slots). The Stacker > Move pull-down menu does this. Release Notes for Stacker 2.1.2 (upgrade from stacker 2.1 or 2.1.1)—January 2000 Page 5 Warnings WARNING: found local version of allocscr.pr You may see ERROR or WARNING messages during the installation. These are due to local COSbackup versions of certain files. The installation script creates new versions of certain COSbackup files. If local versions of these files exist (in the local COSbackup directory structure), they will be used as templates for the new files instead of the original files. As it is impossible to ascertain the modifications made to these local versions, the new files created may not be correct. The new files are created in the Stacker Module directory. “No default version of module - ignored” dialog box When upgrading from or de-installing Stacker 1.1 the message “No default version of module - ignored” is displayed in a dialog box and cannot be removed. Workaround is to run: Config > COSMOS Configuration > Maintain Tables select application table (applictn) and Change. Modify the ‘installed modules’ field to remove the stacker entry. Hardware and OS Dependencies Determining what device to use on AIX 4 Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1. The AIX 4.x stacker routines require a kernel stacker driver to be installed. The kernel driver is supplied with the stacker routines, in the Driver directory. This driver must be installed seperately, using SMIT or the installp program from the command line. See the README file for instructions on installing the kernel driver. Once installed, a new SMIT menu will be setup under “Devices” to allow you to add and remove stacker devices. The stacker device would be /dev/chgr0, created at ‘4,1’ on the appropriate SCSI adapter. The non-rewinding tape device would be /dev/rmt1.1, created at ‘4,0’ on the same SCSI adapter. Release Notes for Stacker 2.1.2 (upgrade from stacker 2.1 or 2.1.1)—January 2000 Page 6 These devices are configured using SMIT. Determining what device to use on DU 3.2 Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1. The Digital Unix stacker routines use the generic user agent SCSI device driver. This provides access to the SCSI/CAM subsystem and to all SCSI/CAM devices attached to the system. The SCSI commands are sent to the device via the special device called /dev/cam. To support the stacker COSbackup needs to have a dummy device entry in the following format: /dev/b0t0l0 where b = bus t = target id l = lun In our example, the stacker device would be /dev/b0t4l1. This device does not need to exist, it is only used to inform the stacker routines of which SCSI device to interface to. Determining what device to use on DU 4.0 Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1. The Digital Unix stacker routines use the CAM interface, which provides SCSI pass-through facility via the generic /dev/cam device. There is no entry in /dev created fro the stacker itself, and in order to define the stacker device to COSbackup, use a dummy device entry: /dev/scsiXtYlZ where X is the SCSI bus number, Y is the target ID, and Z is the LUN of the stacker. In our example, if the stacker is on SCSI bus 0, the media changer device would be: /dev/scsi0t4l1 The determine the correct values to use, look in /var/adm/messages, and look for an entry like: vmunix: changer at scsi 0 target 4 lun 1 (LID=4) Release Notes for Stacker 2.1.2 (upgrade from stacker 2.1 or 2.1.1)—January 2000 Page 7 The tape drive will be called /dev/rmtNX (where N is a number allocated sequentially from 0, and X is a letter [l, m, h or a] determining the density or compression used when writing the tape). The non-rewinding device is prefixed with ‘n’. A command like: file /dev/rmt0h when run as root will give the SCSI details of the tape device. Determining what device to use on HP/UX 10 Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1. The HP/UX stacker routines use the generic SCSI pass-through driver, scsi_ctl(7). The stacker device can either be an appropriate entry under the directory /dev/scsi, if one exists (for example, /dev/scsi/4 for a device at ID 4, LUN 0) or you can create an entry called, for example, /dev/stkr0 using mknod using the instructions in scsi_ctl(7). HP/UX tape devices are allocated sequentially, their name does not correspond directly to their SCSI ID. See HP/UX documentation for how to determine the name of the tape devices. Determining what device to use on IRIX 6 Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1. The IRIX stacker routines use the generic user mode SCSI driver, ds(7M). The stacker device would be/dev/scsi/sc0d4l0. The non-rewinding tape device would be/dev/rmt/tps0d4nr. These devices can be configured by running /dev/MAKEDEV scsi rmt command. The IRIX stacker driver requires that you have the ‘ds’ driver in your kernel. The driver is not always included on some hardware. If the file /var/sysgen/system/irix.sm contains a line, ‘USE: ds’, then the driver is included. If the file /var/sysgen/system/irix.sm contains a line, ‘*INCLUDE: ds’, then the driver is not included. Remove the comment character ‘*’, then relink the kernel by invoking /etc/autoconfig. Release Notes for Stacker 2.1.2 (upgrade from stacker 2.1 or 2.1.1)—January 2000 Page 8 Another way to tell whether the ‘ds’ driver is included in your kernel is to check the kernel symbols: nm /unix | egrep “dsinit|dsopen|dsclose” The IRIX driver may produce occasional unknown sense key warning messages. Determining what device to use on Linux 2.2 kernel Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1. The linux stacker routines use the SCSI Generic (SG) Linux driver, which provides a SCSI passthrough facility using the device entries: /dev/sgX Where X is a letter starting from ‘a’ for the first SCSI device on the system, ‘b’ for the second and so on. The easiest way to determine which ‘sg’ device to use is to view the file: /proc/scsi/scsi which will list all the SCSI devices on the system. The position of the stacker device (that will be listed as a “Medium Changer”) gives the letter to use. For example, the 3rd SCSI device will be /dev/sgc. Caution If you add or remove SCSI devices from the system, the position of the stacker in the SCSI list may change, which means that you will have to change the device name. Determining what device to use on Dynix/ptx 4 Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1. To use a stacker unter ptx, it must be supported by one of ptx’s media changer drivers (mx, ms or ml). Stackers can be configured in two ways. A simple random access stacker (without barcode support nor import/export slots) can be configured to use ptx’s mc(1) command. To support larger tape libraries with barcode and/or import/export slots, the COSbackup driver (stkrctrl) must be used. This requires PTX 4.4.2 SPDRIVERS. Release Notes for Stacker 2.1.2 (upgrade from stacker 2.1 or 2.1.1)—January 2000 Page 9 In our example, the stacker device woud be /dev/ms0, and the non-rewinding tape device /dev/td0n. Determining what device to use on Solaris 2 Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1. The Solaris stacker routines require a kernel stacker driver to be installed. The kernel driver is supplied with the stacker routines, in the Driver directory. See the README file for instructions on onstalling the kernel driver as it will not be installed automatically. The stacker device would be /dev/stkr4. Solaris tape devices are allocated sequentially, their name does not correspond directly to their SCSI ID. See Solaris documentation for how to determine the name of tape devices. Known Problems AIX auto-configure creates two stacker devices instead of one The AIX device driver can get confused when auto-configuring some autoloaders. This is because the driver uses the SCSI Product ID reported by the device to determine if the device is a stacker. Many autoloaders report the same Product ID for the tape drive and the stacker robot, and the driver mistakenly creates two stacker devices instead of one. This may also create a conflict with SCSI tape driver. Workaround is to use SMIT to remove the stacker device created on the tape drive ID/LUN. You may then have to ‘add’ or ‘configure’ the tape device again. IRIX reports error sense info The IRIX stacker driver may report: Error: sense info: key=0x02, asc=0x3a, ascq=0x00 when attempting to load from an unoccupied slot, load to an occupied drive, unload to an occupied slot, or unload from an unoccupied drive. This is not a fatal error, as the operation being performed is incorrect, and should not occur under normal operation. Release Notes for Stacker 2.1.2 (upgrade from stacker 2.1 or 2.1.1)—January 2000 Page 10 We have abserved that the IRIX SCSI driver returns before the stacker robot has stopped moving when unloading tapes. It may be necessary to sleep a short while before trying a load operation immediately following an unload. Dynix/ptx reports “Move medium command failed” The Dynix/ptx SCSI media changer driver does not report detailed error status. Hence a message like “Move medium command failed” is all that can be reported, rather than specifying more detail (such as the source slot being empty).



January 2000
Copyright © 1990-2024 Functional Software. All rights reserved.