DSA Recovery

When recovering a lost DSA server, all top-level BigFix relays (and therefore the entire deployment) should already be pointing to the remaining DSA server.

It is recommended to leave all relays and clients reporting up to the working DSA server during this recovery procedure. If your existing relay settings do not allow this, isolate the server being restored on the network such that only the working DSA server can connect to it.

If the master DSA server fails, run the following procedure on the BFEnterprise database to promote the secondary DSA server to master during restoration and replication of the failed server.
```
db2
  set schema dbo
  select serverid from DBINFO (take count of SERVERID)
  set current function path dbo 
  call update_adminFields('Z:masterDatabaseServerID','<serverid>') - Replace 
SERVERID with the value from the previous query
```
In this way, you can install a new DSA server and you can run the Administration Tool on the secondary DSA server during the restoration of the failed server.
On the existing DSA server, delete the failed DSA server id from the database:
1. List the IDs of the DSA servers:
```
select * from REPLICATION_SERVERS
```
2. After identifying the failed server ID, run the following procedure:
```
call dbo.delete_replication_server(ID)
```
Restore the server operating system and database software in a pristine state without any BigFix server or the BigFix database remnants.
If you followed the server backup procedure described at:
Server Backup
Follow the server recovery procedure, starting from Step 3, described at:
Server Recovery
Stop the BigFix FillDB process, set the following keywords in the besserver.config file and restart the FillDB process.
```
PerformanceDataPath = <Performance_Data_Path_filename>
UnInterruptibleReplicationSeconds = 14400
ReplicationDatabase=<DBName>
ReplicationUser=<DBUser>
ReplicationPassword=<DBPassword> 
```
where <Performance_Data_Path_filename> might be /var/opt/BESServer/FillDBData/FillDBPerf.log.

After replication completes, run the following procedure in the database to promote this newly restored BigFix server to be the master server.

db2
  set schema dbo
  select serverid from DBINFO (take count of SERVERID)
  set current function path dbo 
  call update_adminFields('Z:masterDatabaseServerID','<serverid>') - Replace 
SERVERID with the value from the previous query

Reinstall and reconfigure the plug-ins. Configuration information can be gathered from the currently operating DSA server or from installation notes and configuration details kept by the Administrator.
Set the following keywords in the besserver.config file and restart the BES FillDB service:
```
PerformanceDataPath = ""
UnInterruptibleReplicationSeconds = 120 
```
Launch the Administration Tool and update the replication interval on this restored server to the desired level. Typically, this value should match the interval set on the other DSA server.
Note: Depending on the size of the deployment, the replication process might take multiple days to complete. To validate its completion, look for a Replication Completed message in the FillDBperf.log file. Connecting a separate BigFix console to each DSA server and comparing contents is another way to check that the data is synchronized in both deployments.
Revalidate the datasource on the Web Reports, editing the existing one.

Note: When you switch the servers, you have to wait for the endpoints to register with the new master server before you can send mailbox actions to them. Endpoints register automatically and periodically to a server by default every 6 hours. In the meantime, if you need to run any actions, this can be accomplished by running them as Dynamically target by property.