Depending on your company policies, you can choose your backup strategy.
This topic contains the following information:
How is data stored by the product?
Before you decide your backup strategy, you need to understand how data is stored by the product.
The following table provides information at a high level, about the different kinds of data, that you need to backup.
| Kind of data | Stored by | Description |
|---|---|---|
| User defined configurations, related default settings, and polling status of data collectors | Configuration Database | Data related to all the configurations that can be performed from the UI are stored by the Configuration Database. For example, data collectors, data patterns, notifications, and saved searches. All default settings related to the user configurations that are available after you install or upgrade the product are also stored by the Configuration Database. For example, data retention period, tags, and default data patterns. |
| System configuration data and related default settings | Configuration files | All the system configurations and property definitions are stored in the configuration files. For example, polling batch and time settings, location of the indexed data, and location of the Configuration Database data. For more information, see Modifying the configuration files. |
| Data collected from your data file and indexed by the product | Indexer | All indexed data is stored by the Indexer. Each index contains data for the configured number of hours. Multiple files are created for each index. If you need a backup of the historical data for search and notification alerts, the indexed data must be backed up. You need to backup data from each individual Indexer node in the cluster. For more information, see Indexer cluster. |
Guidelines for deciding your backup strategy
The following table provides guidelines and recommendations that you can use for deciding your backup strategy:
| Action | When |
|---|---|
| Perform a backup of the Configuration Database. | Daily or multiple times in the day depending on how critical is your data. For example, suppose you perform a backup of the Configuration Database at the end of each day. If you create many data collectors and data patterns in the middle of the day, you might not want to wait until the end of the day (when the next backup cycle starts), to perform a backup of the significant changes made. |
| Perform a backup of the configuration files. | Each time you make changes in the configuration files. You need a backup of the configuration files only to capture all the custom changes made to the default settings. |
| Perform a backup of the indexed data. | Before performing an upgrade and depending on your company policies. |
For more information, see Backing up and restoring data.
Additional measures for performing ad-hoc backup activities
The following table provides additional measures that you can use individually when you make any significant configuration changes (related to data collection). These are basic measures that can help you against data loss without requiring the need for restoring the Configuration Database.
| Action | When | Additional information |
|---|---|---|
Export newly created data collectors by using the This can be useful in a scenario where the system crashes and you want to restore all the exported data collectors by using the | Each time you create a new data collector. | exportcollector |
| importcollector | ||
| Export newly created data patterns and collection profiles as a part of the content pack. | Each time you create a new data pattern or collection profile. | Managing content packs |
Overview
Content Tools
Apps
Reporter Replacement
com.bmc.atlassian.bmc-util-plugin-2.section.label
Tasks