The database contains all information about the library configuration and the location of all library cartridges.
ACSLS control files that are backed up and are recovered include the customer-configurable files located in $ ACS_home under data/external and some files located in data/internal/client_config.
This chapter discusses: importing and exporting the database; verifying the imported database and library configuration; backing up the database; and restoring and recovering the database.
Exporting and Importing the database includes:
Exporting the database to a disk file or local tape device
Importing the database from a disk file or local tape device
Importing ACSLS control configuration files
Merging any customized dynamic variables
Verifying the imported database and library configuration
Backing up the database and ACSLS control files includes:
Automatic database backup
Performing manual backups to a local tape device or to disk
Backing up to a UNIX File
Creating a backup that can be restored to a different server
Recovering and restoring the database and ACSLS control files includes:
Restoring the database to the most recent backup
Recovering from a specific file
Restoring ACSLS control files
Restoring a backup created on a different server
Restarting the database
You will use the following utilities:
The bdb.acsss utility for backups to a:
specified UNIX file
tape device
default file and location
The rdb.acsss utility for:
recovering the database from corruption
from changes that produce unintended results
from server failure
The db_export.sh and db_import.sh utilities for migrating between versions of ACSLS. This includes going to a later release, or going to a previous release.
When you install ACSLS, you also automatically install the database management software. The ACSLS database is initialized after ACSLS is installed when you:
configure the library hardware using acsss_config
import a previous exported database using db_import.sh
recover a database backup created on a different server using rbd.acsss.sh
This section describes how to migrate the ACSLS database and its associated ACSLS control files from either a previous version of ACSLS, the same release level of ACSLS, or return to a prior release.
Note:
You cannot rundb_export.sh while ACSLS is running. This ensures that you get a consistent copy of the database.The db_export.sh utility creates an ASCII representation of the database on tape or a specified file to disk. It is also responsible for gathering ACSLS control files. This utility can be used in two different ways.
If it is executed without any options, the exported files are copied to the default tape device: /dev/rmt/0n
db_export.sh
If you want to use a different tape device, use the -f option, followed by the desired tape device:
db_export.sh -f /dev/rmt/3n
If you want to export to a local file on the same machine, specify the file path name using the -f option:
db_export.sh -f /export/save/acsls_export.03_Dec_2014
When saving to a file, the result is two separate files. The database tables is saved in the file name you specify. The miscellaneous control files have the identical path name with a.misc extension.
The files generated by db_export.sh are then used as input to the db_import.sh utility at the time of an upgrade or recovery.
Note:
This is the preferred method for migrating all previous ACSLS versions to the current version.When executing the db_export.sh utility either with the -f option or without, you will be prompted to choose the version of ACSLS to which you are exporting.
$ db_export.sh
Exporting database to /dev/tape
Choose the release to which you are exporting by selecting from the options below:
If exporting to tape, a no-rewind device is required.
1: ACSLS 5.3.2 or 5.4 2: ACSLS 6.0 or 6.0.1 3: ACSLS 6.0.1 with L700e 4: ACSLS 6.0.1 with PUT0201 5: ACSLS 6.1, 7.0, or 7.1/7.1.1 before PUT0701 6: ACSLS 7.1/7.1.1 with PUT0701 or ACSLS 7.2 (any) 7: ACSLS 7.3 (any) 8: ACSLS 8.0, 8.01, 8.02, and 8.1 9: ACSLS 8.2 or later E: Exit
If you are exporting your database to an earlier release of ACSLS that does not support some of your tape libraries, tape drives, or cartridge media types, remove the unsupported tape libraries from your configuration, tape drives and cartridges from your libraries before exporting your database. Otherwise, the following may occur:
If you select an earlier ACSLS release that does not support a library, you are prompted to remove the library from your configuration before exporting your database.
If you export tape drives to an earlier ACSLS release that does not support them, the drives are reported as ”unknown,” and you are unable to use them.
If you export cartridges to an earlier ACSLS release that does not support their media type(s), the cartridges are marked as absent, and you must manually remove them from your libraries.
ACSLS running on Linux does not support logical libraries accessed using a Fibre target. If you are exporting your database to ACSLS running on Linux, remove any logical libraries. Otherwise, you will not be able to use any logical libraries running on Linux.
You can export the ACSLS database and ACSLS control files to a disk file, as shown in the following procedure.
Log in as acsss.
Disable ACSLS:
acsss disable (from a UNIX command prompt)
Start the db_export.sh utility.
db_export.sh -f /path/db_file
Select the desired option for the version to which you are migrating.
As it executes, the utility displays output indicating successful table data being exported.
When the export is complete, a message is displayed indicating that the export has been successful.
The db_export.sh utility creates two files: db_file and db_file.misc in the location specified with the -f option.
Ensure that these files are placed in or moved to a secure location where they will not be removed.
Do not put these files in or under the following directories, as the directories may be removed or deleted when ACSLS maintenance is installed:
$ACS_HOME(the ACSSS home directory)
$ACSDB_BACKUP_DIR (such as /export/backup)(directory where ACSLS backups are stored)
/tmp
Note:
If you plan to install a new release of the operating system, do not save the exported files on the ACSLS server.To start ACSLS and the database, enter the following command:
acsss enable
You can export the ACSLS database and ACSLS control files to tape, as shown in the following procedure.
To export the database and ACSLS control files to tape:
Log in as acsss.
Disable ACSLS:
acsss disable (from a UNIX command prompt)
Insert a blank tape into the default tape device.
Start the db_export.sh utility;
db_export.sh -f tape_device
Example: dbexport.sh -f /dev/rmt/0mn
Select the desired option from which you are exporting.
As it executes, the utility displays output indicating successful table data being exported and successful ACSLS files being backed up. A message displays when the export is completed.
Remove the cartridge from the drive only when the program completes and the prompt re-appears.
Caution:
You will lose files if you remove the cartridge before the program completes the export. Write ”protect the cartridge” and clearly mark it to identify the contents as the exported database.Do not leave the cartridge in the library.
To start ACSLS and the database, enter the following command:
acsss enable
The following attributes are imported into the new database when you use the db_import.sh utility.
Volumes: These database tables include all of the information associated with each volume in the library, such as:
where the volume resides
type of cartridge (such as data, scratch, and cleaning)
last associated scratch pool
current status of the cartridge (home, mounted, and so on)
entry date and last accessed date
number of mounts since the entry date
maximum use (for cleaning cartridges)
associated lock ID and user ID (if the cartridge is locked)
ACS and Library: database tables include the ACSs and library components, such as: LSMs, drives, panels, and cells
ACSLS control files include all configuration updates since the initial installation, including:
access control information
fixed volume preferences
scratch media preferences
custom volrpt templates
Dynamic and static variables: dynamic variables that have been customized in a previous release can be imported
This section describes how to use the db_import.sh utility to:
recreate the ACSLS database
recover important ACSLS control files
recover customized dynamic variables from data exported using the db_export.sh utility.
You can import the ACSLS database and ACSLS control files from a disk file, as shown in the following procedure.
To import the ACSLS database, ACSLS control files, or customized dynamic variables from a disk file:
Log in as acsss.
Disable ACSLS.
acsss disable (from a UNIX command prompt)
Start the db_import.sh utility.
db_import.sh -f db_file
ACSLS Import Utility
If importing from tape, a no-rewind device is required.
What would you like to do:
1) Import data, control files, and dynamic variables from
from a DIFFERENT release or platform version of ACSLS (upgrade)
2) Import data, control files, and dynamic variables from the SAME
release (version and PUT level) and platform of ACSLS(Disaster Recovery)
3) Import database tables only (any level of ACSLS)
4) Import control files only (any level of ACSLS)
5. Merge customized dynamic variables only (any level of ACSLS)
E) Exit
Please select one of the above:
Option 1 - importing data, control files, and dynamic variables from a different release or platform version.
Use this option to import database files, control files, and dynamic variables when moving to a different release or upgrading ACSLS.
Caution:
Existing database and control tables and dynamic variable settings, are destroyed, re-built, and populated with the data provided from the export. The results are final and there is no recovery without rebuilding the database. To preserve information in existing tables, do not continue unless you have exported the table data usingdb_export.sh.This option also recovers customized dynamic variables from previous environments. This is useful when upgrading versions of ACSLS without having to record previous customized dynamic variables. All files in the directory acs.home under data/external including access control files are recovered. If access control is configured, it also recovers data/internal/client_config.
Option 2 - importing data, control files, and dynamic variables from the same release or platform version
Use this option to recreate an ACSLS environment, including both the database and the control files. This would be used when:
recovering from a hardware failure or during a hardware upgrade.
you must rebuild the ACSLS server to be identical to the ACSLS server from which the data was exported.
Option 3 - importing only database tables from any ACSLS release level
Use this option to import only database files from any ACSLS release level.
This option destroys the existing database tables and control files, rebuilds them, and then populates them with the data provided from the exported database. To preserve information in existing tables, do not continue unless you have exported the data using db_export.sh
Option 4 - importing ACSLS control files from any ACSLS release level
Use this option to import only ACSLS control files either from any version of ACSLS. This imports all files in the directory acs.home under data/external including access control files. If access control is configured, it also imports data/internal/client_config.
This option recovers ACSLS database files, control files, and dynamic variable from the same version. This recovers all files in the directory acs.home under data/external, including access control files.
This option recovers customized dynamic variables from previous environments. This is a very useful option for upgrading versions of ACSLS without having to record previous customized dynamic variables.
Selecting this option gathers the settings from the database export, and then reconfigures shared memory with the new variable settings.
Option 5 - merging only customized dynamic variables
This is a very useful option for upgrading versions of ACSLS without having to record previously customized dynamic variables. Selecting this option gathers the settings from the database export and reconfigures shared memory with the new variable settings.
WARNING:
If you are importing from ACSLS 7.2.0 and if you start ACSLS before executing this option, certain data could be lost. If you are upgrading ACSLS from a previous version and had customized dynamic variables, you should import your customized variables BEFORE starting ACSLS.
Verify the install as described under "Verifying the Imported Database and Library Configuration".
To start ACSLS, enter the following command:
acsss enable
Use the following procedure to import the ACSLS database, recover ACSLS control files, and rebuild customized dynamic variables from tape.
Log in as acsss.
Disable ACSLS.
acsss disable (from a UNIX command prompt)
Insert the exported database tape that you exported with the db_export.sh command into the tape drive.
Run the database import utility by entering the following at a UNIX command prompt.
db_import.sh
The db_import.sh utility displays its main menu as shown in "Importing From a Disk File". It also provides more information.
Note:
You receive an ”unsuccessful” message if you run thedb_import utility from one terminal while doing a tape rewind from a different terminal.Refer to the step "Start the db_import.sh utility." for menu options.
Verify the install as described in "Verifying the Imported Database and Library Configuration".
Import from tape, other than the default tape device (no rewind).
To start ACSLS, enter the following command:
acsss enable
The SCSI Media Changer (mchanger) is the Fibre attached library device driver that communicates between ACSLS and any Fibre attached library. A mchanger must be created for each Fibre attached library that is connected to ACSLS.
The numbers in /dev/mchanger# device driver links may change when importing ACSLS to another platform and/or release which can create problems. For example, an SL500 or SL150 library that was connected through /dev/mchanger3 on the old ACSLS server may be connected through /dev/mchanger4 on the new ACSLS server.
This is not an issue when going from one ACSLS Linux server to a new Linux server because the format of mchanger names is different on Linux. Instead of a number, on Linux servers, the mchanger name includes the library serial number.
The following procedure avoids problems when you have media changer drivers configured for Fibre-attached libraries and migrate to a new ACSLS release or server platform.
On a Solaris or AIX ACSLS server, record the mchanger number associated with each Fibre-attached library on the old ACSLS server. See "Record Details about Fibre-attached Libraries on the Old ACSLS Server".
Update your configuration with the new mchanger names for the libraries. See "Reconfigure ACSLS to Change mchanger Names for Fibre-attached Libraries".
On a Solaris or AIX ACSLS server, before exporting the database from the old ACSLS server, record the mchanger number associated with each Fibre-attached library on the old ACSLS server. Save the output from cmd_proc and the showDevs.sh utility that shows the mchanger associated with each Fibre-attached ACS and the serial numbers of the libraries.
cmd_proc:
query lmu all
This shows all ACSs controlled by ACSLS and their port connections. The port names for Fibre-attached libraries on Solaris and AIX systems will be /dev/mchanger#, where # is a number
display lsm * -f type serial_num
This displays the library type and serial number of all LSMs managed by ACSLS. Use library type, such as SL500 or SL150, to identify the Fibre-attached libraries. Use the serial number to identify the specific library.
Utilities:
showDevs.sh -s
The showDevs.sh utility with the –s option shows the mchanger device link, the library type, the library serial number, and details which identify the Fibre-attached library.
After importing your database, if you are either migrating to or from Linux, or the same mchanger numbers were not configured on Solaris, you must update your configuration with the new mchanger names for these libraries.
Using acsss_config:
Log in as acsss.
Use showDevs.sh to display all of your Fibre-attached libraries.
The showDevs.sh utility with the –s option shows the mchanger device link, the library type, the library serial number, and details which identify the Fibre-attached library.
Save the output from showDevs.sh in a file so you can copy and paste it into prompts from acsss_config.
With the output from showDevs.sh -s displayed in one terminal window, open a second terminal window and log in as acsss.
Run acsss_config in the second terminal window.
Select Option 8: Define or Change Library Configuration.
Reply y to Configure library communications? (y/n):
Reply y to Library server data base exists and will be overwritten, continue (y or n)?
Referencing the saved output from query lmu all, reconfigure all of the ACSs that were configured on your old ACSLS server.
Configure all of the ACSs in the same order, and with the same ACS numbers as they were on the old ACSLS server.
Configure the non Fibre-attached libraries as partitioned or not partitioned, and with the same port connections as they had on the old ACSLS server.
When configuring the port connections for your Fibre-attached libraries, specify the new mchanger link names used on the new ACSLS server. For mchanger link names on Linux, the easy way to do this is copy them from the showDevs.sh output and paste them after the acsss_config prompt.
Finish reconfiguring your ACSLS library hardware.
Use the following procedure to mount or dismount a cartridge to verify ACSLS.
Verify that you are logged in as acsss.
If ACSLS is not running, start it by entering the following command:
acsss enable
Query the server from the cmd_proc by entering the following command:
query server
If messages are displayed indicating that the server is in recovery mode, wait for a message indicating that the server is running.
Verify that the following are online. If not, bring them online with the vary command.
query port all
query acs all
query lsm all
query drive all
Do you have at least one cartridge in an LSM:
YES - Continue with the procedure.
NO - Enter a cartridge into an LSM.
Mount a cartridge by entering the following command:
mount vol_id drive_id
Use the query drive command to get the ID of an available drive and the query volume command to get the ID of a library cartridge.
Did you see a message indicating a successful mount?
A successful mount message is:
Mount: vol_id mounted on drive_id
YES - Procedure is complete.
NO - If an error message appears, run this verification procedure again to ensure that you specified a valid, available drive and a library cartridge. If the mount or dismount still fails, call Support for assistance.
Dismount the cartridge by entering the following command:
dismount vol_id drive_id force
where vol_id is the volume and drive_id is the drive you specified in Step 6.
ACSLS automatically creates a backup file of the database-to-disk every 24 hours at midnight, or, the time of day and days of the week you specified in the backup options in acsss_config.
In addition to the automatic database backups that ACSLS creates, you should periodically run the bdb.acsss utility to manually create tape backups that can be stored off-site and used, if needed, for disaster recovery of the database.
Regular backups transferred to an off-site device can enable rapid restoration if disaster to the ACSLS server occurs.
Use bdb.acsss to manually back up the database to tape after:
Running acsss_config.
Importing the database.
An audit of the entire library.
Any database recovery.
To backup the ACSLS database to a specified tape device attached to the ACSLS server, do the following:
Log in as acsss.
Insert a blank tape into the tape device.
From a terminal window, enter the following command:
bdb.acsss -f tape_device
Where tape_device specifies a tape device attached to the ACSLS server.
Messages reporting the progress of the backup appear.
Wait for the following message to appear:
Check tape device (/dev/rmt/0mn) to make sure you have a tape in the tape drive.
[Hit RETURN to continue or Ctrl-C to exit]
Press RETURN.
Wait for the following message to appear:
ACSLS database backup successfully completed.
Example: To backup the ACSLS database to tape device /dev/rmt/0mn, enter the following command:
bdb.acsss -f /dev/rmt/0mn
In the interest of disaster recovery, Oracle does not recommend that you backup to a UNIX file unless the file is on a remote disk. See"bdb.acsss".
To back up the ACSLS database to a UNIX file, do the following:
Log in as acsss.
From a terminal window enter the following command:
bdb.acsss -f db_file
Where db_file specifies a UNIX file to contain the ACSLS database. You must have write permissions to the file.
Wait for the following message to appear:
ACSLS database backup successfully completed.
This section describes the following restoration/recovery procedures:
Restoring a corrupted or lost database to the most recent backup
Restoring a corrupted or lost database to a specified date and time
Recovering from a disk failure
Disaster recovery for a failed server
Recovering from a specific backup file
Restoring non-database, ACSLS control files
Most of these procedures use the rdb.acsss utility, which provides options for restoring a database from the most recent backup, or from a specified date and time; disaster recovery using a backup created by bdb.acsss; and restoring ACSLS control files created by bdb.acsss. For more information about these options, see "rdb.acsss".
Note:
If the home cell of a cartridge changes from its last location after a backup, then the restored database will not be up-to-date. To avoid cartridge movement on dismounts: each LSM must be the only LSM in its ACS (true in most SCSI libraries), or the Extended Store Feature must be enabled for all LSMs that are connected to other LSMs through a pass-thru-port.For more information, see "Using the Extended Store Feature". If the Extended Store Feature is not enabled for all connected LSMs or cartridges have been entered or ejected, audit the library after the restoration to make the database current, and enable all LSMs that are connected to other LSMs through a pass-thru-port.
Note:
Do not specify the-f option as a general option for the rdb.acsss utility. If you backed up your database to an external network file or to an alternate tape device, use the -f option only after entering rdb.acsss. Choose the third recovery option. When prompted, enter -f and the path name to your external network file or an alternate tape device. See "Select option 2:" for more information.In this procedure, you restore the database to the most recent backup created on the local disk by automatic backups. ACSLS control files are also restored.
To restore a corrupted or lost database to the most recent backup, complete the following steps:
Log in as acsss.
Disable ACSLS.
acsss disable
Enter the following command:
rdb.acsss
Select option 1:
1. Restore from a current local disk backup
Refer to "rdb.acsss" for procedures.
To start ACSLS, enter the following command:
acsss enable
Use this procedure for a disaster recovery when you have lost or corrupted both primary and secondary disks.
To recover from a failed server, complete the following:
Install the operating system.
Install ACSLS.
Caution:
You must install ACSLS in the same directory you used before the disk failure.Log in as acsss.
Disable ACSLS:
acsss disable
Enter the following command:
rdb.acsss
Select option 2:
2. Restore from a previous tape or network file backup
Refer to "rdb.acsss" for procedures.
To start ACSLS, enter the following command:
acsss enable
You must run acsss_config to re-specify automated backup date and time and retention periods unless you want to accept the default settings.
In this procedure, you restore ACSLS control files. These are non-database files that include all files in the data/external directory such as access control files, the fixed volume file, the scratch preferences file, and custom volrpt files. These files are restored from a bdb.acsss backup-to-tape or an external network file.
To restore ACSLS control files, complete the following:
Log in as acsss.
Disable ACSLS:
acsss disable
Enter the following command:
rdb.acsss
Select option 4:
Restore only ACSLS non-database control files
Refer to "rdb.acsss" for procedures.
To start ACSLS and the database, enter the following command:
acsss enable