This section includes the following topics:
It is essential that you perform regular automatic backups of the STA database to protect your site from potential data loss due to issues such as software crashes, hardware failures, or human error.
Oracle recommends that you implement a backup strategy that includes the following best practices.
Using mirrored or RAID drives for the database on the STA server helps to protect against a single drive failure.
Back up the database regularly, and schedule full backups when database and server activity is low. The STA Backup service provides an easy way to do this; see "About the STA Backup Service" for details. Frequent backups enable you to recover the database to a state close to current.
External backups protect your data from an operating system or hardware failure on the STA server. See "Prepare an External Backup Server" for instructions.
The required space on the backup server is variable—the size should be a multiple of the size used for the STA database local backup, depending on the number of copies to be retained. Backup server storage should be mirrored or striped.
If you back up the database to an external server, you can use a backup service of your choice to manage the files according to your site policies. Absent a backup service, you can set up a Linux cron job to delete old backups.
Archived backups provide added protection in case your most recent backup is corrupted. Depending on your site policies, you can archive backups to tape or another server. A suggested practice is to archive files more than one or two weeks old and delete archives more than one or two months old.
It is the customer's responsibility to manage space on the STA server and the backup server. To help keep the active database at a reasonable size, STA automatically rolls off detailed exchange and SNMP trap data that is more than 60 days old.
Oracle recommends that usage for any partition should never exceed 80 percent. You can use STA Resource Monitor to define high-water marks for disk usage, and the Resource Monitor will alert you if these are exceeded. See "Monitoring STA Server Resources" for details.
The STA Backup service allows you schedule regular backups of the STA database and save them to a designated location on either the STA server or an external server. It automatically performs a daily full backup of the STA database and key STA configuration directories and saves incremental backups at the intervals you specify. These are hot backups, meaning they are done while the MySQL server and the STA application are running.
The STA Backup service is disabled by default when STA is installed, and you must configure the service to enable it. You configure the STA Backup service with the staservadm utility. See "staservadm Utility Reference" for command usage details. The STA Backup service is managed by the STA services daemon; see "STA Services Daemon" for details.
Use of the STA Backup service is optional; if you have a preferred backup application at your site, you can use that instead.
Once enabled, the STA Backup service runs in the background and performs the following process. See "STA Backup Service Files" for details about the contents and locations of all files that are created.
Once a day, at the time you have specified, the service performs the following actions.
Uses the mysqldump command to create a high-speed dump of the current STA database (see "Define the Time of Day for Full Backups" for instructions).
Transfers all existing backup files to the backup location you have specified (see "Define Backup Host Information" for details). This includes the following files:
Database dump file just created
Compressed STA services and WebLogic configuration directories
All incremental backups (binary log files) created in the past 24 hours
These files are purged from the local STA server, but if you are doing remote backups, the STA Backup service never deletes files from the external server. For remote backups, the files are compressed before being transferred to the external server.
Opens a new binary log file to save database changes that occur from this point forward.
Periodically, at the time interval you have specified, the service closes the current binary log file and opens a new one (see "Define the Interval Between Incremental Backups" for details). This step is repeated at the intervals you have specified until the next full backup.
Note:
These tasks use the staservadm utility, which requires the STA Services Daemon; see "Display the Status of the STA Services Daemon" to verify that the daemon is running.See "Using the staservadm Utility" for usage details.
Use this procedure to display the current settings for the STA Backup service.
Open a terminal session on the STA server, and log in as the Oracle user.
Display the current STA Backup service settings.
Example 2-1 and Example 2-2 are sample outputs.
Example 2-1 STA Backup not configured
In this example the STA Backup service is disabled and therefore not performing any backups. The values displayed are the parameter defaults.
$ staservadm -Q
Contacting daemon...connected.
Querying Preferences.
Current STA Backup Service Settings:
Configured [no]
File Transfer -S [SCP]
Full Backup -T [00:00]
Sleep Interval -i [300 sec]
Backup Hostname -s []
Backup Username -u []
Backup Password -p []
Backup Directory -d []
Database Username -U []
Database Password -P []
=====================================
Example 2-2 STA Backup configured
In this example, the STA Backup service is enabled and configured.
$ staservadm –Q
Contacting daemon...connected.
Querying Preferences.
Current STA Backup Service Settings:
Configured [yes]
File Transfer –S [SCP]
Full Backup –T [23:00]
Sleep Interval –i [350 sec]
Backup Hostname –s [stabackup]
Backup Username –u [root]
Backup Password –p [*******]
Backup Directory –d [/dbbackup]
Database Username –U [stadba]
Database Password –P [*********]
=====================================
When STA is installed, the STA Backup service is disabled by default. Use this procedure to enable the service. Once enabled, the STA Backup service performs automatic full and incremental backups of the STA database according to the defined settings.
To enable the service, all parameters must be defined. For parameters with default values, you can retain the defaults or define new values.
You can designate a directory where the backup files will be copied. Oracle recommends that you locate this directory on an external backup server.
Open a terminal session on the STA server, and log in as the Oracle user.
To enable the service, define the required parameters in one or more commands.
$ staservadm -s stabackup -d /dbbackup -u root -p -U stadba -P
Enter server password:
Enter database password:
Contacting daemon...connected.
Setting Backup Hostname...... stabackup
Setting Backup Username...... root
Setting Backup Password...... *******
Setting Backup Directory..... /dbbackup
Setting Database Username.... stadba
Setting Database Password.... *******
Done.
Current STA Backup Service Settings:
Configured [yes]
File Transfer -S [SCP]
Full Backup -T [00:00]
Sleep Interval -i [300 sec]
Backup Hostname -s [stabackup]
Backup Username -u [root]
Backup Password -p [*******]
Backup Directory -d [/dbbackup]
Database Username -U [stadba]
Database Password -P [*******]
=====================================
The utility will perform the first full backup at the time indicated and incremental backups periodically after that; you to not need to stop and restart the STA services daemon.
Use this procedure to clear all STA Backup service preference settings and disable the service. When disabled, the service does not perform backups.
Open a terminal session on the STA server, and log in as the Oracle user.
Clear all preference settings.
$ ./staservadm –C
Contacting daemon...connected.
Clearing Preferences.
Done.
Current STA Backup Service Settings:
Configured [no]
File Transfer –S [SCP]
Full Backup –T [00:00]
Sleep Interval –i [300 sec]
Backup Hostname –s []
Backup Username –u []
Backup Password –p []
Backup Directory –d []
Database Username –U []
Database Password –P []
=====================================
The service is disabled immediately; you do not need to stop and restart the STA services daemon.
Use this procedure to define the time of day when full backups are performed.
Open a terminal session on the STA server, and log in as the Oracle user.
Define the time of day to perform the backups; this is according to the system time on the STA server. In this example, the time is set to 23:30.
$ staservadm -T 23:30
Contacting daemon...connected.
Setting Full Backup Time..... 23:30
Done.
Current STA Backup Service Settings:
Configured [yes]
File Transfer -S [SCP]
Full Backup -T [23:30]
Sleep Interval -i [1800 sec]
Backup Hostname -s [stabackup]
Backup Username -u [root]
Backup Password -p [*******]
Backup Directory -d [/dbbackup]
Database Username -U [root]
Database Password -P [******]
=====================================
If you want the new time to take effect immediately, you must stop and restart the STA services daemon. See "Stop the STA Services Daemon" and "Start the STA Services Daemon" for instructions.
Use this procedure to define the number of seconds between incremental backups.
Open a terminal session on the STA server, and log in as the Oracle user.
Define the interval between backups, in seconds.
In this example, the interval is set to 1800 seconds, or 30 minutes.
$ staservadm -i 1800
Setting Sleep Interval........ 1800 Done.
If you want the new interval to take effect immediately, you must stop and restart the STA services daemon. See "Stop the STA Services Daemon" and "Start the STA Services Daemon" for instructions.
Use this procedure to configure an external server for use by the STA Backup service.
Oracle recommends backing up the database to an external backup server. The required space is variable—the size should be a multiple of the size used for the STA database local backup, depending on the number of copies to be retained. Backup server storage should be mirrored or striped.
Before beginning this procedure, you must obtain the names and credentials of the Oracle user and group used on the STA server. Because the STA Backup service is run as the Oracle user, and this user owns all STA backups, you must create this same user and group on the external backup server. See the STA Installation and Configuration Guide for details about the Oracle user and group.
Note:
This procedure is performed entirely on the external backup server and requires system root access.Open a terminal session on the external server, and log in as the system root user.
Create the Oracle group. For example:
# groupadd oinstall
Create the Oracle user and assign the same password as on the STA server. For example:
# useradd -g oinstall -d /home/oracle oracle # passwd oracle Changing password for user oracle. New password: Retype new password: passwd: all authentication tokens updated successfully.
where:
-g oinstall assigns the user to the Oracle group.
-d /home/oracle creates the user's home directory.
Create the directory where the STA backups will be written. For example:
# mkdir -p /remote_backups/STAbackups
where:
-p creates the parent directory if it does not exist already.
/remote_backups/STAbackups is the absolute path to the new directory.
Assign ownership of the backup directory to the Oracle user and group. For example:
# chown -R oracle:oinstall /remote_backups/STAbackups
where:
-R indicates to recursively assign the specified attributes to the directory and its files.
List the directory to confirm that all information has been entered correctly. For example:
# ls -l /remote_backups
total 4
drwxr-xr-x 2 oracle oinstall 256000 Jan 2 13:20 STAbackups
Use this procedure to specify the following information about the backup host:
File transfer method (SCP or FTP)
Backup host name or IP address
Target directory on the backup host
Backup username and password; if you specify the username, you must also specify the password.
Note:
Oracle recommends backing up the database to an external backup server. See "Prepare an External Backup Server" to configure the backup server for use with the STA Backup service.Open a terminal session on the STA server, and log in as the Oracle user.
Specify the backup host information. To specify the password, you can use either of the following methods:
Enter -p and the password in clear text on the command line.
Enter -p with no password on the command line. When you submit the command, the utility prompts for the password, which is hidden when you type it.
In this example, the utility prompts for the password.
$ staservadm -s stabackup -d /dbbackup -u root -p
Enter server password:
Contacting daemon...connected.
Setting Backup Hostname...... stabackup
Setting Backup Username...... root
Setting Backup Password...... *******
Setting Backup Directory..... /dbbackup
Done.
Current STA Backup Service Settings:
Configured [yes]
File Transfer -S [SCP]
Full Backup -T [00:00]
Sleep Interval -i [300 sec]
Backup Hostname -s [stabackup]
Backup Username -u [root]
Backup Password -p [*******]
Backup Directory -d [/dbbackup]
Database Username -U [stadba]
Database Password -P [*******]
=====================================
If you want the new settings to take effect immediately, you must stop and restart the STA services daemon. See "Stop the STA Services Daemon" and "Start the STA Services Daemon" for instructions.
Use this procedure to specify the MySQL account that the STA Backup service uses to connect to the MySQL server and perform the backups. This must be the MySQL database administrator account created during STA installation.
Open a terminal session on the STA server, and log in as the Oracle user.
Specify the MySQL database administrator username and password. You can use either of the following methods to specify the password:
Enter -P and the password in clear text on the command line.
Enter -P with no password on the command line. When you submit the command, the utility prompts for the password, which is hidden when you type it.
In this example, the utility prompts for the password.
$ staservadm -U stadba -P
Enter database password:
Contacting daemon...connected.
Setting Database Username.... stadba
Setting Database Password.... *******
Done.
If you want the new settings to take effect immediately, you must stop and restart the STA services daemon. See "Stop the STA Services Daemon" and "Start the STA Services Daemon" for instructions.
Use this procedure to find STA server log entries for a backup.
Open a terminal session on the STA server, and log in as the Oracle user.
Change to the STA services log directory.
$ cd /var/log/tbi/db/backups
Use any of the following searches to find log entries for the backup.
Note:
Depending on the amount of log activity and when the backup was performed, entries for the backup in question may be in the current log file (staservd.log.0) or an earlier one (staservd.log.1, staservd.log.2, and so on). You may need to search more than one log file to find the applicable entries.Display all backups recorded in the log file. In this example, backups for January 21 through 23 are included in the staservd.log.1 log file.
$ grep 'StaBackup' staservd.log.1 | grep 'Database dump completed'
INFO: {StaBackup} done. Database dump completed, file located at /dbbackup/local/20160121_111203.stafullbackup.sql
INFO: {StaBackup} done. Database dump completed, file located at /dbbackup/local/20160122_170231.stafullbackup.sql
INFO: {StaBackup} done. Database dump completed, file located at /dbbackup/local/20160123_170250.stafullbackup.sql
Refine the search to display entries just for the backup in question. This example shows entries for the backup done on January 23, 2016.
$ grep 'StaBackup' staservd.log.1 | grep 20160123
INFO: {StaBackup} sending file /dbbackup/local/20160123_170250.conf.zip to stabackup.mycompany.com
INFO: {StaBackup} sending file /dbbackup/local/20160123_170250.fmwconfig.zip to stabackup.mycompany.com
INFO: {StaBackup} done. Database dump completed, file located at /dbbackup/local/20160123_170250.stafullbackup.sql
INFO: {StaBackup} sending file /dbbackup/local/20160123_170250.stafullbackup.sql to stabackup.mycompany.com
Refine the search to display the name of the host where the files for the backup in question were sent. In this example, the files were sent to stabackup.mycompany.com. This may be the local server or an external server.
$ grep 'StaBackup' staservd.log.1 | grep 20160123 | grep 'sending file'
INFO: {StaBackup} sending file /dbbackup/local/20160123_170250.conf.zip to stabackup.mycompany.com
INFO: {StaBackup} sending file /dbbackup/local/20160123_170250.fmwconfig.zip to stabackup.mycompany.com
INFO: {StaBackup} sending file /dbbackup/local/20160123_170250.stafullbackup.sql to stabackup.mycompany.com
Use the following steps to verify that files for a full backup have been successfully saved to the right location and to check the size of the files.
Open a terminal session on the applicable server, and log in as the Oracle user.
Note:
The backup directory may be on the local STA server or an external server. The location is defined by the staservadm utility; see "Display Current STA Backup Settings" for instructions on displaying the location.Oracle recommends backing up the database to an external backup server.
Change to the backup directory. The following example shows an external backup server.
$ cd /remote_backups/stabackups
List the files for the backup in question. This example includes the following files for the full backup done on January 23, 2016.
A full dump of the STA database, identified by the file name ending in stafullbackup.sql.
MySQL server configuration files, identified by the file name ending in fmwconfig.zip.
STA services configuration files, identified by the file name ending in conf.zip.
$ ls -l *20160123*
-rw-r--r-- 1 oracle oinstall 11081 Jan 23 17:02 20160123_170250.conf.zip.gz
-rw-r--r-- 1 oracle oinstall 195524 Jan 23 17:02 20160123_170250.fmwconfig.zip.gz
-rw-r--r-- 1 oracle oinstall 37968 Jan 24 17:03 20160123_170250.stadb-bin.000028.gz
-rw-r--r-- 1 oracle oinstall 461721 Jan 23 17:02 20160123_170250.stafullbackup.sql.gz
Use the following steps to list the incremental backups (binary log files) created since the last full backup. Incremental backups are always located on the local STA server.
Note:
Frequent incremental backups can generate a significant number of binary log files that may consume considerable hard drive space. You may want to purge old binary logs periodically.Open a terminal session on the STA server, and log in as the Oracle user.
Change to the incremental backup directory.
$ cd /var/log/tbi/db
List the directory. This example shows the following incremental backup files:
Incremental backups (binary log files), which have the file names stadb-bin.000028 and stadb-bin.000029. These files are created at the intervals defined with the staservadm utility (see "Define the Interval Between Incremental Backups" for instructions).
Index file for the binary log files, which has the name stadb-bin.index.
"Slow queries" log, which has the name stadb-slow.log. This log lists MySQL queries that take a long time to execute and is a tool used by Oracle Service and development.
$ ls -l
total 876
drwxr--r-- 2 oracle oinstall 4096 Jan 24 02:52 backups
-rw-rw---- 1 oracle oinstall 161351 Jan 24 17:03 stadb-bin.000028
-rw-rw---- 1 oracle oinstall 146592 Jan 25 14:55 stadb-bin.000029
-rw-rw---- 1 oracle oinstall 66 Jan 24 17:03 stadb-bin.index
-rw------- 1 oracle oinstall 6561 Jan 24 17:03 stadb-slow.log
When doing a database restore, you may not want to apply an entire incremental backup file if you suspect it contains corrupted database operations. In this case, you can view the contents of the binary log to identify the valid events you want to apply.
To view binary log events, you must use the MySQL mysqlbinlog utility. The utility converts the binary file contents to text form. This procedure provides some sample methods for using the utility. See the mysqlbinlog utility reference for complete details.
Example 2-3 View Binary Log Contents Directly
$ mysqlbinlog stadb-bin.000016 | more
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#160125 17:03:36 server id 1 end_log_pos 120 CRC32 0x2a76ef3b Start: binlog v 4, server v 5.6.18-enterprise-commercial
-advanced-log created 160125 17:03:36
BINLOG '
2LemVg8BAAAAdAAAAHgAAAAAAAQANS42LjE4LWVudGVycHJpc2UtY29tbWVyY2lhbC1hZHZhbmNl
ZC1sb2cAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAATvv
dio=
'/*!*/;
# at 120
--More--
Example 2-4 Save Binary Log Contents to a Text File for Viewing
$ mysqlbinlog stadb-bin.000030 > ./tmpfile $ tail tmpfile SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/; FLUSH TABLES /*!*/; # at 172335 #160126 17:04:01 server id 1 end_log_pos 172382 CRC32 0x5ab0deca Rotate to stadb-bin.000031 pos: 4 DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/; $
Open a terminal session on the STA server, and log in as the Oracle user.
List the STA services log directory. For example:
$ ls -l /var/log/tbi/db/backups total 3268 -rw-r--r-- 1 oracle oinstall 87255 Jan 7 14:53 staresmonadm.log.0 -rw-r--r-- 1 oracle oinstall 46017 Jan 22 12:42 staservadm.log.0 -rw-r--r-- 1 oracle oinstall 173908 Jan 25 12:32 staservd.log.0 -rw-r--r-- 1 oracle oinstall 0 Jan 21 16:47 staservd.log.0.lck -rw-r--r-- 1 oracle oinstall 1000085 Jan 24 02:52 staservd.log.1 -rw-r--r-- 1 oracle oinstall 1000226 Jan 16 02:45 staservd.log.2 -rw-r--r-- 1 oracle oinstall 1000104 Jan 8 02:05 staservd.log.3
To determine which services log includes entries for the date you want to confirm, use the following search:
Use the following steps to list the most recent full backup.
Change to the local backup subdirectory for your site. For example:
$ cd /dbbackup/local
List the directory.
$ ls –l
total 23573716
-rw-r--r-- 1 oracle oinstall 11807 Jan 8 00:03 20160108_240323.conf.zip
-rw-r--r-- 1 oracle oinstall 266625 Jan 8 00:03 20160108_240323.fmwconfig.zip
-rw-r--r-- 1 oracle oinstall 23294354241 Jan 8 02:40 20160108_240323.stafullbackup.sql
For additional information about restoring a MySQL database, see the MySQL documentation at the following site:
http://docs.oracle.com/en/database/
This process restores the database to the point when the last incremental backup was completed. You load the most recent full database dump and then apply the incremental backups created since the dump. Depending on the size of your database and the number of incremental backups, this may be a lengthy process.
To restore the STA database, perform the tasks in the order listed.
Either of the following procedures, depending on which incremental backups need to be restored:
Use this procedure if the STA server experienced a catastrophic failure and you need to install and configure a replacement STA server.
Note:
The replacement server must run the same version of Linux and STA as the original STA server.Install Linux on the replacement server. See the STA Installation and Configuration Guide for instructions.
Install STA on the replacement server. See the STA Installation and Configuration Guide for instructions.
Add the replacement server as an SNMP trap recipient on all libraries monitored by STA. See the STA Installation and Configuration Guide for instructions.
Use this procedure to copy the complete set of files for the most recent backup from the backup server to the STA server. This includes the most recent full database dump file and all incremental backups created since then.
On the backup server, copy the backup files to the STA server.
Open a terminal session on the backup server, and log in as the Oracle user. If you are only doing local backups, this is the STA server.
Copy the complete set of one day's backup files to the STA server. Oracle recommends copying the files to the /tmp directory. For example:
$ scp *20160123* staserver.mycompany.com:/tmp/.
oracle@staserver.mycompany.com's password:
20160123_170250.conf.zip.gz 100% 11KB 10.8KB/s 00:00
20160123_170250.fmwconfig.zip.gz 100% 191KB 190.9KB/s 00:00
20160123_170250.stadb-bin.000028.gz 100% 37KB 37.1KB/s 00:00
20160123_170250.stafullbackup.sql.gz 100% 451KB 450.9KB/s 00:00
where:
*20160123* indicates to copy all files with this date stamp.
staserver.mycompany.com is the name of the STA server.
/tmp is the target directory.
On the STA server, verify and decompress the files.
Open a terminal session on the STA server, and log in as the Oracle user.
Change to the target directory and verify the compressed files were successfully copied.
$ cd /tmp $ ls -l *20160123* -rw-r--r-- 1 oracle oinstall 11081 Jan 27 15:18 20160123_170250.conf.zip.gz -rw-r--r-- 1 oracle oinstall 195524 Jan 27 15:18 20160123_170250.fmwconfig.zip.gz -rw-r--r-- 1 oracle oinstall 37968 Jan 27 15:18 20160123_170250.stadb-bin.000028.gz -rw-r--r-- 1 oracle oinstall 461721 Jan 27 15:18 20160123_170250.stafullbackup.sql.gz
Unzip the compressed files.
$ gunzip *20160123*.gz $ ls -l *20160123* -rw-r--r-- 1 oracle oinstall 11939 Jan 27 15:18 20160123_170250.conf.zip -rw-r--r-- 1 oracle oinstall 259328 Jan 27 15:18 20160123_170250.fmwconfig.zip -rw-r--r-- 1 oracle oinstall 161351 Jan 27 15:18 20160123_170250.stadb-bin.000028 -rw-r--r-- 1 oracle oinstall 3653692 Jan 27 15:18 20160123_170250.stafullbackup.sql
Use this procedure to restore the STA service and server configuration directory files. To ensure a clean restore, remove any existing directories after first backing them up, and then completely replace the directories from the backups.
The backup zip files were created with the full directory paths to allow you to restore or overwrite existing files.
Note:
This procedure is performed entirely on the STA server.Open a terminal session on the STA server, and log in as the Oracle user.
Stop all STA processes. See "Stop the STA Application" for details.
$ STA stop all
Restart the MySQL server. See "Start the MySQL Server" for details.
$ STA start mysql
As a safeguard, save the existing STA services configuration directory to a zip file. For example:
$ cd /Oracle/StorageTek_Tape_Analytics/common $ zip –vr conf.orig.zip conf adding: conf/ (in=0) (out=0) (stored 0%) adding: conf/staservadm.log.props (in=934) (out=355) (deflated 62%) ... total bytes=102262, compressed=10598 -> 90% savings $
As a safeguard, save the existing database server configuration directory to a zip file. For example:
$ cd /Oracle/Middleware/user_projects/domains/TBI/config $ zip –vr fmwconfig.orig.zip fmwconfig adding: fmwconfig/ (stored 0%) adding: fmwconfig/mbeans/ (stored 0%) adding: fmwconfig/mbeans/jps_mbeans.xml (deflated 72%) ... total bytes=1846687, compressed=222531 -> 88% savings $
Delete the existing configuration directories.
$ rm –rf /Oracle/StorageTek_Tape_Analytics/common/conf $ rm -rf /Oracle/Middleware/user_projects/domains/TBI/config/fmwconfig
Unzip the backup STA services and database server configuration directories. For example:
$ cd /tmp $ unzip -X -d / 20160123_170250.conf.zip Archive: 20160123_170250.conf.zip warning: stripped absolute path spec from /Oracle/StorageTek_Tape_Analytics/common/conf/staservadm.log.props inflating: /Oracle/StorageTek_Tape_Analytics/common/conf/staservadm.log.props warning: stripped absolute path spec from /Oracle/StorageTek_Tape_Analytics/common/conf/staresmonadm.log.props inflating: /Oracle/StorageTek_Tape_Analytics/common/conf/staresmonadm.log.props ... $ $ unzip -X -d / 20160123_170250.fmwconfig.zip Archive: 20160123_170250.fmwconfig.zipwarning: stripped absolute path spec from /Oracle/Middleware/user_projects/domains/TBI/config/fmwconfig/mbeans/jps_mbeans.xml inflating: /Oracle/Middleware/user_projects/domains/TBI/config/fmwconfig/mbeans/jps_mbeans.xmlwarning: stripped absolute path spec from /Oracle/Middleware/user_projects/domains/TBI/config/fmwconfig/mbeans/igf_mbeans.xml inflating: /Oracle/Middleware/user_projects/domains/TBI/config/fmwconfig/mbeans/igf_mbeans.xml ... $
where:
-X indicates to restore user and group ownership.
-d / indicates to restore the files to the root directory (/). Since the backup zip files were created using the full directory paths for each file, this restores the files to their original locations.
Verify the configuration directories have been restored. For example:
$ ls -l /Oracle/StorageTek_Tape_Analytics/common $ ls -l /Oracle/Middleware/user_projects/domains/TBI/config
Use this procedure to reload the STA database from the full database dump.
Open a terminal session on the STA server, and log in as the Oracle user.
Ensure there is no residual STA database left on the server. The STA database has the name stadb. For example:
$ mysql –u root –p –e 'drop database stadb;'
Password:
where:
-u root indicates to execute the command as the MySQL root user
-p indicates to prompt for the user password.
-e indicates to execute the following MySQL statement and then quit the mysql command. The statement must be enclosed in quotes.
'drop database stadb'—Removes the database named stadb, which is the STA database.
Load the latest full database backup. For example:
$ mysql –u root –p –e 'source 20130723_133755.stafullbackup.sql;'
Password:
where:
-u root specifies the MySQL root username.
-p indicates to prompt for the user password.
-e indicates to execute the following MySQL statement and then quit the mysql command. The statement must be enclosed in quotes.
'source 20130723_133755.stafullbackup.sql;'— Executes the specified database dump file; the dump file creates the schema and installs all the data.
Continue to either of the following procedures, depending on whether you want to restore all incremental backups or only selected ones.
To restore all incremental backups created after the last full dump, see "Perform a Full Restore From All Incremental Backups".
To restore only a range of incremental backups, see "Perform a Partial Restore From a Range of Log Numbers". Use this procedure if you suspect a database operation may have corrupted the database and you only want to restore operations up to, but not including, that one.
Use this procedure to restore all incremental backups (binary logs) since the last full backup, in the proper order. This procedure uses the MySQL mysqlbinlog utility.
Open a terminal session on the STA server, and log in as the Oracle user.
Run the binary logs in chronological order, from oldest to newest.
If you have more than one binary log to execute, you should process them all using a single connection to the MySQL server. Use one of the following methods:
The safest method is to use a single connection to the server and a single MySQL process to execute the contents of all the binary logs. For example:
$ mysqlbinlog 20130723_133755.sta-binlog.000021 \ > 20130723_133755.sta-binlog.000022 \ > 20130723_133755.sta-binlog.000023 \ > 20130723_133755.sta-binlog.000024 |mysql –u root –p Password:
Another safe method is to concatenate all applicable binary logs to a single file and then process that file. For example:
$ mysqlbinlog 20130723_133755.sta-binlog.000021 > /tmp/recoversta.sql $ mysqlbinlog 20130723_133755.sta-binlog.000022 >> /tmp/recoversta.sql $ mysqlbinlog 20130723_133755.sta-binlog.000023 >> /tmp/recoversta.sql $ mysqlbinlog 20130723_133755.sta-binlog.000024 >> /tmp/recoversta.sql $ mysql –u root –p –e 'source /tmp/recoversta.sql' Password:
Caution:
Do not use multiple connections to the MySQL server. Multiple connections cause problems if the first log file contains a CREATE TEMPORARY TABLE statement and the second log contains a statement that uses that temporary table. When the first MySQL process terminates, the server drops the temporary table. When the second MySQL process attempts to use that table, the server reports "unknown table."Following is an example of how not to process the binary logs, as this method may create multiple connections to the server.
$ mysqlbinlog binlog.000001 |mysql –u root –p #<=== DANGER!! $ mysqlbinlog binlog.000002 |mysql –u root –p #<=== DANGER!!
Use this procedure to do a partial restore of the STA database, also known as a point-in-time restore, from a range of log numbers. Using this method, you restore the database from the last full dump and then apply just the binary log operations that fall within the start and end points you specify.
Log positions are labeled in the binary log as log_pos followed by a unique number.
For example, after examining the contents of a binary log, you discover that an erroneous operation resulted in dropping several tables immediately following log entry #6817916. Therefore, you want to restore the database only up to the last good entry (#6817916), excluding the erroneous operation and all that follow.
In this procedure, you restore the database from the full dump done the day before, and then replay the most recent binary log from its initial log entry number "176" through entry number "6817916".
Open a terminal session on the STA server, and log in as the Oracle user.
Stop all STA processes. See "Stop the STA Application" for details.
$ STA stop all
Restart the MySQL server. See "Start the MySQL Server" for details.
$ STA start mysql
Open a terminal session on the STA server, and log in as the Oracle user.
Extract the valid operations from the binary logs. For example:
$ mysqlbinlog ––start–position=176 ––stop–position=6817916 /var/log/tbi/db/stadb–bin.000007 > ./recover.sql
Password:
where:
--start-position is the first log entry you want to extract.
--stop-position is the last log entry you want to extract. In this example, entries 176 to 6817916 are extracted.
/var/log/tbi/db/stadb-bin.00007 is the binary log file you want to extract from.
./recover.sql is the file you want to write the entries to.
Apply the selected operations to the database. For example:
$ mysql –u root –p –e 'source ./recover.sql'
Password:
where:
-u root specifies the STA database root username.
-p indicates to prompt for the user password.
-e indicates to execute the following MySQL statement and then quit the mysql command. The statement must be enclosed in quotes.
'source ./recover.sql'—Applies the entries in the specified file to the database.
Open a terminal session on the STA server, and log in as the Oracle user.
Restart STA and all associated processes; see "Start the STA Application" for instructions.
The se tasks assume the new (target) server will use the same version of STA as the current server. To upgrade the database to a new version of STA, see the upgrade instructions in the STA Installation and Configuration Guide.
Following are some reasons why you may want to transfer the STA database to another server.
You may want to replace the current STA server with a new one, in which case you need to permanently relocate the database.
You may want to test a feature you have not used before, such as STA media validation or alerts, in which case you want to temporarily set up another instance of STA with a fully populated database.
To transfer the STA database, perform the tasks in the order listed.
Use this procedure to prepare the target server for the STA database. The target server must run the same version of Linux and STA as the current STA server.
Install Linux on the target server. See the STA Installation and Configuration Guide for instructions.
Install STA on the target server. See the STA Installation and Configuration Guide for instructions.
Perform the following steps on all libraries monitored by STA.
Add the target server as an SNMP trap recipient; this will cause the libraries to send SNMP data to the target server. See the STA Installation and Configuration Guide for instructions.
If the target server is replacing the current STA server, remove the current STA server as an SNMP trap recipient; this will cause the libraries to stop sending SNMP data to the current server. See the STA Installation and Configuration Guide for instructions.
Use this procedure to perform a full dump of the current STA database.
Note:
This procedure is performed entirely on the current STA server.Display the size of your current STA database.
Open a browser window and log in to STA.
Click About in the Status Bar.
In the About dialog box, scroll down to where the Database Current Size is displayed, and record the value.
Verify that the location where you want to dump the database has sufficient space.
Open a terminal session on the STA server, and log in as the Oracle user.
Display the space available in the database dump destination, and verify it is sufficient for the dump file. The following example checks the space in /tmp.
$ df -h /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sta_server-STA_DbVol 200G 53G 243G 27% /
Stop all STA processes. See "Stop the STA Application" for details.
$ STA stop all
Restart the MySQL server. See "Start the MySQL Server" for details.
$ STA start mysql
Dump the STA database into a single file. Enter the database root user password when prompted. For example:
$ mysqldump -u root -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /tmp/160115_SavedSTADatabase.sql
Enter password:
$
where:
-u root specifies the STA database root username.
-p indicates to prompt for the user password.
--flush-logs indicates to flush the MySQL server log files before starting the dump.
--databases stadb specifies the name of the database to dump.
/tmp/160115_SavedSTADatabase.sql specifies the name of the dump file to create. The name must end with .sql.
For descriptions of the other options, see the MySQL Reference Manual.
Note:
The --verbose command option is not recommended, as it displays many messages in the terminal window and can significantly slow down the command process for large databases.Verify the dump file has been created, and note the size. You will use the size information in the next procedure. For example:
$ cd /tmp $ ls -l 160115*sql -rw-r--r-- 1 oracle oinstall 3875509 Jan 15 14:05 160115_SavedSTADatabase.sql
To reduce the dump file size by approximately 50 percent, compress the file. For example:
$ gzip 160115_SavedSTADatabase.sql $ ls -l 160115*gz -rw-r--r-- 1 oracle oinstall 365282 Jan 15 14:34 160115_SavedSTADatabase.sql.gz
Use this procedure to transfer the compressed STA database dump file to the target server and then decompress it there. The decompressed database may require 10 to 15 times as much space as the compressed database.
On the target server, verify there is sufficient space for the decompressed database dump file.
Open a terminal session on the target server and log in as the Oracle user.
Display the space available in the destination directory, and verify it is sufficient for the size of the decompressed dump file, which you displayed in the previous task; see "Dump the STA Database". The following example displays the space in /tmp.
$ df -h /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/newstaserver-lv_root 150G 32G 118G 21% /
On the STA server, transfer the compressed dump file to the target server.
Open a terminal session on the STA server, and log in as the Oracle user.
Transfer the file to the target server using a transfer utility such as SCP. For example:
$ cd /tmp $ scp -p 160115_SavedSTADatabase.sql.gz newstaserver:/tmp
where:
-p indicates to preserve timestamp values from the original files.
160115_SavedSTADatabase.sql.gz is the name of the compressed database dump file.
newstaserver is the name of the target server.
/tmp is the target directory on the server.
On the target server, decompress the database dump file.
Open a terminal session on the target server and log in as the Oracle user.
Decompress the dump file. For example:
$ cd /tmp $ gunzip 160115_SavedSTADatabase.sql.gz $ ls -l 160115*sql -rw-r--r-- 1 oracle oinstall 3875509 Jan 15 15:05 160115_SavedSTADatabase.sql
Use this procedure to load the decompressed dump file into the database on the target server.
Note:
This procedure is performed entirely on the target server.Open a terminal session on the target server, and log in as the Oracle user.
Stop all STA processes. See "Stop the STA Application" for details.
$ STA stop all
Restart the MySQL server. See "Start the MySQL Server" for details.
$ STA start mysql
Load the dump file into the STA database. Enter the database root user password when prompted. For example:
$ mysql -u root -p -e "SET SESSION SQL_LOG_BIN=0; SOURCE /tmp/160115_SavedSTADatabase.sql;" Password: $
where:
-u root specifies the database root username.
-p indicates to prompt for the user password.
-e indicates to execute the following MySQL statements and then quit the mysql command. The statements must be enclosed in quotes.
SET SESSION SQL_LOG_BIN=0;—Temporarily disables binary logging during the load, speeding up the process.
SOURCE /tmp/160115_SavedSTADatabase.sql—Loads the dump file into the database.
There is no command output as the process runs. If the command is successful, you are returned to the command prompt once the process completes.
Note:
The --verbose command option is not recommended, as it displays many messages in the terminal window and can significantly slow down the command process for large databases.Perform the following tasks to fully configure STA on the target server.
Add the target STA server as a trap recipient on the libraries you want STA to monitor. See the library configuration tasks in the STA Installation and Configuration Guide for instructions.
Use the following tasks to configure library connections to each library. See the SNMP connection management tasks in the STA User's Guide for complete instructions. These tasks are all performed on the target server.
Enter the configuration settings for the STA SNMP client.
Reconfigure the SNMP connection to each library you want STA to monitor.
Establish SNMP communication between STA and the libraries by testing the connection to each library.
Get the latest SNMP library configuration data from each library.
Configure STA users and application data, as applicable. These tasks are all performed on the target server.
Create STA usernames and passwords. See the STA User's Guide for instructions.
If the STA email server requires authentication, you must enter the email account username and password. See the STA User's Guide for instructions.
Assign ownership to custom templates, as applicable. See the STA User's Guide for instructions.
Assign ownership to private Executive Report policies, as applicable. See the STA User's Guide for instructions.
Assign ownership to logical groups by recreating the groups, as applicable; see the STA User's Guide for instructions.
Configure the STA backup service on the target server. See "Tasks for Configuring the STA Backup Service".
Configure the STA Resource Monitor on the target server. See "Resource Monitor Tasks".
The staservadm utility is located in the following directory:
where Oracle_storage_home is the Oracle storage home location specified during STA installation.
See "Ensure the Correct Oracle User Path" for instructions on adding the directory to the Oracle user path.
You can use the staservadm utility only if the STA services daemon is running. See "Display the Status of the STA Services Daemon" to verify.
You can submit as many parameters as you want in each staservadm command line; only the parameters you specify are updated, and the unspecified ones remain at their current value.
Changes to the STA Backup service take effect as soon as one of the following actions occurs:
The STA Backup service wakes from its current sleep interval and processes the new settings.
You manually restart the STA services daemon. See "Stop the STA Services Daemon" and "Start the STA Services Daemon" for instructions.
Table 2-1 provides detailed information about the staservadm command parameters. A value of "NA" indicates there is no default value.
Table 2-1 staservadm Parameters
| Parameter | Name | Description | Default Value |
|---|---|---|---|
|
-Q, --query |
Query |
Display the current STA Backup service settings. See "Display Current STA Backup Settings" for instructions. |
NA |
|
-C, --clear |
Clear |
Clear all STA Backup service settings and disable the service. See "Disable the STA Backup Service" for instructions. |
NA |
|
-h, --help |
Help |
Display command usage information |
NA |
|
-T, --time |
Full backup dump time |
Time of day the STA Backup service performs a full database backup, or dump. Format is hh:mm, using 24-hour time. The dump is performed automatically every 24 hours at approximately this time. The actual time is within one incremental backup interval after this time. See "Define the Time of Day for Full Backups" for instructions. |
00:00 |
|
-i, --int |
Interval between incremental backups |
Frequency, in number of seconds, at which the STA Backup service scans the database for changes. If it detects changes, the STA Backup service performs an incremental backup. Valid entries: integers 1 to 86399. See "Define the Interval Between Incremental Backups" for instructions. |
300 |
|
-U, --dbusr |
Database username |
Database user the STA Backup service uses to perform the backups. This must be a user on the STA server that is authorized to perform the mysqldump command—for example, the STA database root user or the STA database administrator. See "Specify the Database Username and Password" for instructions. |
blank |
|
-P, --dbpwd |
Database password |
Password assigned to the database user. See "Specify the Database Username and Password" for instructions. |
blank |
|
-S, --scp | -F, --ftp |
File transfer method |
File transfer method used to copy the backup files from the STA server to the backup host. You can specify either SCP (recommended) or FTP. See "Define Backup Host Information" for instructions. |
SCP |
|
-s, --server |
Backup host name |
Server host to which the STA Backup service copies the backup files. You can specify an IPv4 or IPv6 address, or a fully qualified DNS host name. Oracle recommends using an external server for backups. See "Define Backup Host Information" for instructions. |
NA |
|
-d, --dir |
Target directory |
Target directory on the backup server to which the STA Backup service copies the backup files. This directory must already exist. See "Define Backup Host Information" for instructions. |
NA |
|
-u, --usr |
Backup username |
System username that writes the database backup files to the target directory. This must be a user on the backup server that has write privileges to the target directory. See "Define Backup Host Information" for instructions. |
NA |
|
-p, --pwd |
Backup password |
Password assigned to the backup username. See "Define Backup Host Information" for instructions. |
NA |
This section provides detailed information about the backup files created by the STA Backup service.
A full backup, or database dump, is a complete snapshot of the STA database schema and data contents at a point in time. The dump is created once every 24 hours at the time you have defined with the staservadm utility (see "Define the Time of Day for Full Backups" for instructions).
Each dump file is assigned the following name:
where:
datestamp is the current date in yyyymmdd format.
timestamp is the current time, in hhmmss format.
For example, 20160114_180525.stafullback.sql would be a database dump file created on January 14, 2016 at 18:05:25.
Files for the most recent full backup (full database dump) are located in the /backup_directory/local directory on the STA server, where /backup_directory is the database backup location specified during STA installation (see the STA Installation and Configuration Guide for details). The STA Backup service automatically creates the local subdirectory if it does not exist already.
The STA Backup service automatically removes the previous day's full backup files from this directory when it completes each day's full backup.
If you are not doing remote backups, this is the only backup retained by the STA Backup service. You have only one day's full backup on the local STA server.
If you are doing remote backups, compressed copies of all full backup files are also located in the remote backup directory defined with the staservadm utility (see Define Backup Host Information for instructions).
The STA Backup service never deletes files from the external backup server, enabling you to maintain as many days worth of backups as your site's policies require. Also, it is your responsibility to manage the files and the space on the external server. You can use your site's preferred backup and archiving policies and tools to manage the files.
When the STA Backup service does a full database dump, it also creates compressed copies of the configuration directories for the STA services and WebLogic server, including the STA Resource Monitor and STA Backup service administration logs. These are recursive backups of all the files and directories in their respective configuration directories.
The file names are as follows:
where:
datestamp is the current date in yyyymmdd format.
timestamp is the current time, in hhmmss format.
For example, 20160114_180525.conf.zip and 20160114_180525.fmwconfig.zip would be compressed WebLogic and STA services configuration directories, respectively, created on January 14, 2016 at 18:05:25.
An incremental backup, or binary log, contains records of all transactions that change the database. As the name implies, binary logs are saved in binary format; see "View Binary Log Contents" for information on viewing their contents.
To do a full database restore, you load the most recent full dump file and then apply, in sequential order, all the incremental backups that were generated after the dump. This process enables you to restore the database to its state up to the last transaction recorded in the binary logs.
Each binary log is assigned the following file name:
where:
nnnnnn is a unique number indicating the sequence in which the incremental backups were created.
For example, stadb-bin.000034, stadb-bin.000035, and stadb-bin.000036 could be three successive incremental backups created by the STA Backup service.
All incremental backups created since the last full backup are located in the /var/log/tbi/db directory on the STA server. The number of binary log files in the directory depends on the incremental backup interval you have specified (see Define the Interval Between Incremental Backups for instructions).
The STA Backup service removes all incremental backups from the /var/log/tbi/db directory when it completes a daily full backup. Therefore this directory only contains incremental backup files created since the last full backup. You should never delete binary log files from this directory yourself.
If you are not doing remote backups, the incremental backups are deleted from this directory and not retained anywhere.
If you are doing remote backups, the incremental backups are transferred to the remote backup directory every 24 hours, when the compressed full database dump files are moved (see STA Backup Service Process for details). You can keep as many days worth of incremental backups on the backup server as your site's policies require.