Restore Data Aggregator after an Operating System failure

Document ID : KB000101456
Last Modified Date : 13/07/2018
Show Technical Document Details
Issue:
In this instance an attempted Virtual Machine server move wasn't successful. The server the Data Aggregator is installed on will only boot into a maintenance mode and needs to be rebuilt.

Other problems may also result in similar situations where for whatever reason, the Operating System that the Data Aggregator ran under has become unusable.

How can the CA Data Aggregator be restored on a new system when a situation such as this arises?
Environment:
All supported CA Performance Management releases
Cause:
CA Data Aggregator failures due to Operating System failures that are unable to be resolved.
Resolution:
Two choices exist to resolve this. 

NOTE: Key to both choices is that during the new DA install, ensure that when asked about creating the DR schema choose No. Choosing yes will lead to the new schema overwriting the DR DB. Be sure a DR DB backup is current to use in a restore situation if necessary. 

1: Build new VM using same host name, IP, etc. Install the DA and be sure to choose NO, DO NOT allow it to create the schema. Doing this should allow it to simply restart and connect to the other systems again. 

2: With the files available from the old system we could use a combination of Migrate and Restore instructions: 
https://docops.ca.com/ca-performance-management/3-5/en/administrating/data-aggregator-administration/migrate-the-data-aggregator 
Migrate starts with backing up the DA files. We have the disk save to grab that off. 
Then we copy the files to the new host. 
Then step 4 is restore the DA on the new host. 
https://docops.ca.com/ca-performance-management/3-5/en/administrating/data-aggregator-administration/restore-data-aggregator 
Change to that process for this scenario is in step 2. We won't have one to uninstall. Will still need to run the install. 
Here again ensure we answer NO DO NOT allow schema creation. 

At that point with no other changes needed for the other systems (if new DA uses same name/IP and such) it should begin to work again. 

Can't use just the restore because it needs a working OS which we don't have here. 

This process doesn't talk about the answer to the schema creation question because it's geared toward and environmental migration. In that scenario a new DR would be installed and waiting for the schema, then the DR DB would be loaded into the newly created schema. We're not doing any of that if we don't have to here in this situation.