How can a Control-M/Server with PostgreSQL be failed-over and/or failed-back to/from a DR (Disaster Recovery) Site?

How to failover the Control-M/Server to the DR Site when using Postgres (for Oracle and MSSQL see article number 000156434):

Applicable only when it's necessary to move Control-M/Server with Postgres from Production Site (Site A) to Disaster Recovery Site (Site B), using the latest HotBackup + archives.

1. Prerequisites for moving Site A (the original non-DR Control-M/Server) to Site B (the new DR Control-M/Server):

    (1.1). Perform Hot Backup from active node on Site A, running DBUHotBackup.
    (1.2). Stop the environment on Site A.     (1.4). No Control-M/Server components on Site B are running. (PostgreSQL also down)
    (1.5). The Control-M/Server Version and Fix Pack levels are the same on both Site A and Site B.

2. Actions on the Control-M/Server account on Site B:

*Only perform the first step below if the hostname or port of the database needs to be changed (for example, when a dummy database with a different host or port was used for setting up the Control-M/Server on the DR Site).

    (2.1). If the Control-M/Server was configured to run on another database host or port , execute: restore_host_config -reconf_db (please see KA 000150657 for more information on this command)
    (2.2). Logout/login from the account
    (2.3). Execute: restore_host_config -dr
    (2.4). Start the Control-M/Server configuration agent and then the Control-M/Server running start_ca; start_ctm

Note: If Site B was setup without a Control-M/Secondary server for High Availability running, the “restore_host_config -dr” command will remove its entry (please see KA 000155186 for more information on this).

How to fallback the Control-M/Server from Site B (DR failover site) to Site A (original site):

    (3.1). Perform the following before Hot Backup on Site B (its in order to overcome CAR00188293)     (3.2). Run the DBUHotBackup on Site B
    (3.3). Shut down the server on Site B running: shut_ca; shut_ctm
    (3.4). Copy the tar files created after the Hot Backup and the archives folder to Site A

 4. Option 1: using the same primary installation (no need to reinstall the primary on side A):

    (4.1). Verify Control-M/Server and PostgreSQL are down on Site A
    (4.2). Perform Hot Restore on Site A
    (4.3). Open the /ctm_server/data/localconfig.dat     (4.4). If the Control-M/Server was configured to run on another database host or port , execute: restore_host_config -reconf_db (please see KA 000150657 for more information on this command)
    (4.5) Logout/Login from the account
    (4.6). Execute: restore_host_config -dr
    (4.7). Start the Control-M/Server configuration agent and then the Control-M/Server
    (4.8). If you are using a Control-M/High Availability Environment, and Site B was setup without a Control-M/Secondary High Availability Server, the Secondary HA server will need to be uninstalled and then re-installed (please see KA 000155186 for more information on this).

5. Option 2: If the Control-M/Server installation(s) do not exist on Site A due to the cause of the DR failover:

    (5.1). Install a new Control-M/Server with the same FixPack Level as the Control-M/Server running on Site B.
    (5.2). Perform Hot Restore on Site A     (5.6). Start the Control-M/Server configuration agent and then the Control-M/Server
    (5.7). (Optional) Install a Secondary Control-M/Server if you are using a Control-M/High Availability Environment.