by John Round
Data storage overview
Data is stored in several locations. Here are the main storage areas;
- The Tivoli Enterprise Monitoring Server stores agent attribute information and situation information. It can also store short-term historical monitoring data.
- The Tivoli Enterprise Portal Server stores user and visualization data.
- Agents may also store short-term historical monitoring data (this is actually the preferred location for large environments)
- Tivoli Data Warehouse stores historical data in detailed or summarized form (long-term historical monitoring data)
When planning your backup strategy, you must know the location of the key Tivoli Monitoring data. As mentioned above, you can store short-term historical monitoring data at each agent or at the monitoring server, depending on how you configure historical data collection. Certain types of monitoring agents can store historical data only at the monitoring server or only at the agent. Review the documentation for each agent when designing your backup strategy.
Monitoring server data storage
The Tivoli Enterprise Monitoring Server uses a proprietary database called the Enterprise Information Base (EIB) to store information.
- The hub monitoring server stores a master EIB.
- Each remote monitoring server synchronizes with the hub and stores portions of the EIB relevant to it.
Information that is stored in the EIB includes:
- Situation event data such as situation event status, EIB log, work list, and node status.
- Persistent data such as node lists, access lists, policy definitions, situation definitions, and cross-reference tables.
- Attribute information for every type of agent that is supported by the monitoring server.
Attributes are added when application support is added to the monitoring server. If you collect and save short-term historical data at the Tivoli Enterprise Monitoring Server, this is stored in separate files.
NOTE: You should shut down the monitoring server when backing up such data.
The hub monitoring server maintains EIB tables. On UNIX / Linux the files (*.db and *.idx) are stored under the
- Node lists provide a logical topology view of the entire network. The table is a complete representation of the network environment. This view is important to correlate policy actions that issue across multiple monitoring servers. You see node lists when you assign situations or policies to managed systems.
- Access lists define the targets of a situation and policy. Situations can run on an individual agent or on multiple agents. Access lists manage the distribution of situations and policies to the actual systems.
- Situation and policy lists contain the situation and policy definitions.
For environments that still require a Candle Management Workstation (CMW), the hub monitoring server also stores all CMW data. When you store historical data at the monitoring server, one file stores data from multiple agents.
NOTE: When the two hub monitoring servers are running in the hot standby mode (FTO), they continuously synchronize the data within their Enterprise Information Base.
Synchronized Information
-
Definition objects situations and policies,
-
Information about managed systems,
-
Information about the distribution
-
Information about EIF (Event Integration Facility) SLOT Customization.
Information not Synchronized
Portal server data storage
The Tivoli Enterprise Portal Server uses a relational database which can be DB2, Oracle, Microsoft SQL Server, or a “Derby” database for smaller environments. Data stored in this database includes;
- User IDs and user authorization
- Current and historical logon information
- Workspace definitions, such as views and links
- Query definitions
- Navigator views
- Situation associations with navigator items
- Portal server version information
Other portal server data storage includes the following;
- Sound (.wav) and graphic(.png, .gif, .jpg, .wmf) files that represent background images, icons and sounds. On UNIX / Linux the files are stored under;
On Windows the directory is;
- HTML files for the help content and expert advice of each agent. Each agent has a subdirectory with its product code. On UNIX / Linux the files are stored under;
On Windows the directory is;
The portal clients use these files to provide data to the user in a meaningful way.
Agent data storage
Agents collect data in different ways, depending on the type of agent. This data maps into attributes, which are the values that are shown in the portal client.
Raw data maps into attributes through attribute files (*.atr), which are located at each agent and at the monitoring server (
On UNIX / Linux the files are stored under;
On Windows the directory is;
In addition to attribute information, and as noted previously, you can store short-term historical monitoring data at each agent rather than at the monitoring server. This is dependant on how you configure historical data collection.
NOTE: In addition to using attribute files to map the raw data into attributes. The portal server also uses catalog files (*.cat) to structure attributes in database tables at the monitoring server (RKDSCATL directory). These files also build the basis for *.odi files. The portal server uses these files to read and use attributes and communicate with the monitoring server.
Data backup overview
An enterprise typically has a standard process for preserving a backup image of all computer systems, including the IBM Tivoli Monitoring environment. In most cases, the standard process for your enterprise is preferable to any processes described / shown here.
- When backing up your IBM Tivoli Monitoring infrastructure components, make sure to regularly back up all dynamic files and databases.
- Make backups continuously, but especially before migrating or applying maintenance.
- When possible, stop the monitoring component before backing it up to ensure that data is consistent and correct.
Make sure to back up these files regularly:
- The entire
- The portal server database
Monitoring server backup and restore
Back up all *.db and *.idx files in the
Portal server backup
Backing up the Tivoli Enterprise Portal Server means saving the database and copying other files, for example help files and graphic files, to an archive location.
You can use the migrate-export utilities that Tivoli Monitoring provides to back up the portal server database. These utilities, migrate-export.bat on Windows and migrate-export.sh on UNIX and Linux, export the contents of the database to SQL statements in a text file. The migrate-export utilities stop the portal server before exporting the data.
Windows;
- Run migrate-export.bat in
- Export all database entries and write them to the file saveexport.sql in the directory
UNIX and Linux;
- Move to the
Portal server restore
The migrate-export utilities provide the capability to move a portal server database from one system to another. After exporting the data to a file, you can use the migrate-import utilities to import the data to a new portal server. If you are using the utilities to back up the database, you can use migrate-import when you need to restore the database.
Copy the saveexport.sql file into the directory on a different Tivoli Enterprise Portal Server, or on the same Tivoli Enterprise Portal Server if you want to restore a previous configuration
Windows;
Run migrate-import.bat in
UNIX and Linux;
Move to the
History data backup and restore
History data can be stored in a number of places depending on configuration and data age. The following are the possible directories for short term historical data;
Windows;
Agent:
TEMS:
UNIX and Linux;
Agent:
TEMS:
Use the above directories to backup and restore short term historical data. To backup and restore long term historical data, you should backup and restore the relational database that implements the Tivoli Data Warehouse using appropriate database tools and processes. Here's an overview of the process for DB2;
db2 connect to yourwarehousedatabase
db2 quiesce database immediate force connections
db2 connect reset
db2 backup database yourwarehousedatabase to /yourbackuplocation
db2 connect to yourwarehousedatabase
db2 unquiesce database
db2 connect reset
The following video provides a demonstration of how to manually backup the data and configuration of your TEMS/TEPS on a Linux system.