This appendix:
Outlines and explains each utility, what they are used for, and why they are important.
Provides a high level view of disaster recovery scenarios.
ACSLS offers three robust and distinctly different methods for backing up both its database and ACSLS control files. Each utility performs different functions, and all methods play an important role in a complete disaster recovery plan.
ACSLS provides automated database protection services. These automated protection services safeguard the daily operation of the ACSLS database against changes that can produce either unintended consequences, or from database corruption.
As a result of these automated backup protection services, you have the ability to restore your database back to any backup time from the present to the end of your retention period. The restore tools are discussed later in this appendix.
This section discusses the automated backup methods and why they are used.
ACSLS default backup directory
During the initial installation of ACSLS, you were asked to supply the name of the directory to use for backups (/export/backup by default). It is in this directory that backup activity occurs.
A complete database backup is performed and placed in the directory, using a date naming convention:
/export/backup/yyyy-mm-dd-hh:mm:ss.tar.
The time at which the daily backup is performed can be modified by changing the ”Automatic Backup Variables” within acsss_config.
Refer to "Setting Variables that Control ACSLS Behavior" for information on changing default backup behavior.
Database retention period
Another configurable parameter within ACSLS that affects automatic backups is the database retention period. This is defined as the amount of time ACSLS retains the backups.
The default for the retention period is 8 days.
Refer to "Setting Variables that Control ACSLS Behavior" for information on changing default backup behavior.
The retention period can also be modified by using acsss_config.
ACSLS provides a utility called bdb.acsss that backs up the critical ACSLS data using the command line. This is also the method used to restore the ACSLS database where the environment consists of the same or identical hardware, OS level, and ACSLS version. Refer to "bdb.acsss".
Used without any command line options, bdb.acsss provides the ability to create a database backup and store it in the default backup directory. All critical ACSLS database and ACSLS control files are backed up to a single file. This file can then be used to restore ACSLS to its previous state on the same or identical hardware for scenarios such as an internal disk or motherboard failure.
The rdb_acsss utility allows a ’-f' option that can be used to either specify a file and location (rdb.acsss -f /path/my_file) or a tape device
(-f /dev/rmt/0mn). When using a tape device, you do not provide a file name on the tape device.
ACSLS provides a utility called db_export.sh to export the ACSLS database, ACSLS control files, and any customized dynamic variables. The db_export.sh utility is responsible for dumping the ACSLS database to comma separated ACSII files, making a copy of the ACSLS control files, and making a copy of the dynamic variables. This is the method used to migrate to newer versions of ACSLS and is not recommended for daily backup operations because both ACSLS and the database must be down before performing the export.
The db_export.sh command line utility is the preferred method for migrating the database between different levels of server hardware, OS versions, and different releases of ACSLS. Without options, it can be used with the local default tape device such as /dev/0mn. This tape can then be moved to any location, and ACSLS and its associated ACSLS control files can be restored into any OS version or level of ACSLS.
Note:
Although any tape device can be selected, a no-rewind device should be used. The db_export utility creates two files. If a rewind device is selected, the first file (datafiles) would be overwritten when the second file is created.As in the bdb.acsss utility, the ’-f' option can be used to specify a tape device other than the system default. Simply execute
db_export.sh /dev/0mn or any attached tape device to use this option.
The -f option also allows the database to be exported to the named file. When using this method, you will notice that two files are created - one file that you named and also another file with a .misc extension. Both files must be transferred to the server where the import will take place to ensure a successful import.
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.
The menu selections in db_export.sh are:
1: ACSLS 7.3 2: ACSLS 8.0, 8.0.1, 8.0.2, 8.1 3. ACSLS 8.2 or 8.3 4. ACSLS 8.4 5. ACSLS 8.5 E: Exit Please select by number (or E to exit):
ACSLS uses two different recovery tools to restore all backups and exports. Both of the tools offer a menu driven user interface and easily selectable options. The two utilities are:
rdb.acsss - the recovery tool for both automated and manual backups
db_import.sh - restores an exported database and/or ACSLS control files from the same version of ACSLS, a different version of ACSLS, or from a different hardware platform. This option also allows the recovery of customized dynamic variables.
The rdb.acsss utility restores the ACSLS database and the ACSLS Control files using a backup created by either the automatic backup function or the bdb.acsss utility. The ACSLS Control files are located in $ACS_HOME/data, and define several different environmental variables for ACSLS. They specify Access Control settings, scratch preferences, Extended Store LSMs, custom volrpt settings, and volume attributes (for watch_vols utility), and so forth.
Refer to "rdb.acsss" for options and procedures.
ACSLS provides a db_import.sh utility to restore an exported database from the same version of ACSLS, a different version of ACSLS, or it could even be from a different hardware platform. Like rdb.acsss, it offers an easy to read menu driven user interface, allowing you to select the task that you want to perform.
The db_import.sh utility can work without options, or you can supply the
’-f' option with a path and file name as an argument. Executing db_import.sh from the command line without any options causes the utility to look for the exported database on the local tape device. It first checks for the existence of the exported database, verifies that it is a valid database export file, and then displays a menu with four options.
Note:
You can also supply an-f option with a tape device (-f /dev/rmt/0mn) for a non-default device. Although you can supply any valid tape device, it is a requirement that you supply a no-rewind device. The db_import.sh utility uses two files - one for data and one for control files. If you use a rewind device, after data files are recovered, the tape would be rewound and the control files would fail.If you provide the -f option with a path and file name, db_import.sh uses the supplied file name as the exported database file. As with the local tape device, it first checks to see if the file exists, and then validates that the supplied file name is an exported database file. If the supplied file is a valid export, it displays a menu. The menu options, are:
Option 1 - Import database tables, control files, and dynamic variables for the exported file.
This option brings in the library database plus all of the customized updates that were preserved from the exported version.
Option 2 - Import only database tables from the exported file.
This option brings in the complete library configuration and volume data set, but does not apply any system customizations that were made in the exported version.
Option 3 - Import only control files from the exported file.
This option does not alter the current library database and it brings in only the customizations that had been exported from the previous version.
Option 4 - Merge customized dynamic variables from the exported file.
This option merges any customized settings from the exported version with the current version. See."Setting Variables that Control ACSLS Behavior".
This section discusses disaster scenarios.
As user acsss, stop ACSLS before running the recovery
$ acsss db $ rdb.acsss
Select option 2. Refer to "rdb.acsss".
When recovery is complete, start ACSLS: acsss enable.
Select option 2. Refer to "rdb.acsss".
Start ACSLS and test according to database backup and restore procedures.
Install the operating system.
Configure the new server and OS with the settings from the previous server.
Install ACSLS.
Insert the backup tape or FTP backup file onto the server.
Start the rdb.acsss utility.
Select option 2. Refer to "rdb.acsss".
Exit rdb.acsss.
Start ACSLS and test according to database backup and restore procedures.
Install the operating system.
Install ACSLS.
Place the ACSLS server-to-server backup files in the proper location.
Enter rdb.acsss. Refer to "rdb.acsss"
Select option 3.
When the recovery utility completes, start ACSLS and test according to database backup and restore procedures.