Disaster recovery

Disaster Recovery involves a set of policies, tools and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster. Disaster recovery focuses on the IT or technology systems supporting critical business functions, as opposed to business continuity, which involves keeping all essential aspects of a business functioning despite significant disruptive events. Disaster recovery can therefore be considered a subset of business continuity. Disaster Recovery assumes that the primary site is not recoverable (at least for some time) and represents a process of restoring data and services to a secondary survived site, which is opposite to the process of restoring back to its original place.

 

The implementation of a Disaster Recovery (DR) site envelops the following operations:

 

  1. It is necessary to have a parallel system to that of production, previously configured and tested. This system has to have the same components and versions installed as production, including Identity/Portal/Discovery/Flow, etc. Keep in mind that in order to make the initial setup this system may have completely independent databases from production. Click here to see how to proceed with a new installation of OneContactCC 3.7.
  2. This new system must have a new entry in the OneContactSystem table on the Portal database. (This operation can be made in OneContactBackOffice. Click here to see how.).
  3. This being a parallel system it will have a OnecontactSystem and DiscoveryService databases independent from production and must not be duplicated.
  4. The remaining databases must have all tables duplicated through the LogShipping mechanism implemented in the SQL (Click here for more information). This mechanism has a minimum time of synchronization of one minute. This may be adjusted according to the contracted service level.
  5. It is necessary to have a synchronization mechanism between the production's GlobalStorage and DR's GlobalStorage.
  6. Regarding IdentityServer the only issue is regarding the ConfigurationParameters that by default, once present in the database, will have priority over the configuration file. As some of the configurations are different between Production and DR environments (namely GlobalStoragePath and Certificate Path) a new configuration must be added to the appSettings config file:

            AppSettingsHavePriority

    This parameter must be included at the beginning of the file. Example:

    {
    "AppSettingsHavePriority": true,
    "DatabaseConnectionString": "Data Source=your.source;Initial Catalog=exampleDB;User ID=User; Password=Password",
    "GlobalStoragePath": "\\\\1.1.1.1\\GlobalStorage\\Example_DR",
    "Certificate": {
    "Path": ".\\OLIdSrv.pfx",
    "Password": "password"
    },
  7. In order for the system to be ready for DR it is necessary that the components of the disaster recovery site point to the duplicated databases.
  8. In order to do the switch to DR it is necessary to:
    1. Stop the duplication, setting the databases of the DR available.
    2. Perform an Auto_Fix of OneContactUser in all the databases (this can be avoided with the synchronization of the Users' Ids between production and DR).
    3. Create a OneAdmin instance in DR.
    4. Change the tenant's systemId to the one in the Tenants table in the Portal database in DR.
    5. Boot the DR system in OneAdmin.
    6. Change the OneProxy rules directly in DR.
    7. Make DNS point to the DR.

 

↑