TSCO - Disaster Recovery best pratices

Version 6
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    TrueSight Capacity Optimization


    Capacity Optimization 11.5.01


    10.x and 11.x


    Is there any best pratice for the creation of a DR recovery site for TrueSight Capacity Optimization?


    In this article, we are providing some basic guidelines that each customer should consider when designing a disaster recovery (DR) strategy to support application resiliency.

    Each customer is responsible for selecting the appropriate commercial tool that meet their organizational requirements to implement the DR strategy.

    These best pratices are valid only for the TSCO servers.
    For TrueSight Presentation Server (TSPS) and for Remedy Single Sign-on (RSSO) please refer to the products documentation

    General rule

    The hostnames need to be the same in both the environment (production and DR). 
    The reason is this: the hostnames are written in TSCO configuration properties (stored on files or on DB) and the hostname are used in order to communicate internally or with the DB. 
    Please refer to this documentation page to understand the communication between the servers 

    The main rule for the DR recovery for TSCO it is keep in sync the file systems of the TSCO servers and content of the DB instances between the active nodes and the DR ones. 
    The idea is making a synchronization at least once a day, but the frequency can be increase according with the size of the data to synchronize and environment performance (network and hardware) 
    Here some quick hints, dived by server functionality  

    Application Server

    For the application server, a sync between the deployment folder of the production server (default /opt/bmc/BCO) with the same path of the DR server it is enough. 
    A specific consideration (see after) is for the repository folder  


    • On AS machine: if the FS is on the Application Server as local folder (shared with other AS), you need to synchronize this folder as reported in Application Server paragraph
    • On a remote folder: if the repository is on a remote folder (like on a NAS), you need to create a remove folder in the same way and keep in sync between production and DR

    ETL Engine:

    The considerations are the same for the AS. Remember that all the routes to the data sources (e.g. route to the vCenters) need to be opened  


    If you want to create a DB for the DR site, this DB need to be an exact copy of the production one and this DB need to be in sync with the production one. A misalignment between the production and DR database can cause a data gap if there is a node switch. 
    Also, some configuration properties are stored in the DB and this is another reason for the need of a synchronization. 

    One of this property is the connection string to the database and, for this reason, also the service name need to be the same between production and DR. 


    Article Number:


    Article Type:


      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles