SOAR disaster recovery prerequisites

Before you deploy a disaster recovery system, ensure that your SOAR Platform environment meets these requirements.

You need two SOAR appliances, a primary appliance and a secondary (receiver) appliance.
The secondary appliance must have the same SOAR Platform version as the primary appliance.

The secondary appliance does not require any SOAR Platform configuration, apart from the DR setup described in this guide. File system changes on monitored directories and database transactions are replicated automatically to the secondary appliance.

In a disaster situation, the secondary appliance must be capable of taking on role of the primary appliance, so both appliances must have a similar hardware configuration.

Note: You do not need to deploy a SOAR license file to the secondary appliance, as that license file is propagated from the primary appliance.
Both SOAR appliances must be the Virtual Appliance variation. The standalone installation (.run file) is not supported.
You must have the SOAR OVA file and the optional packages for that version of the SOAR Platform.
You must have a resadmin account available for use on the primary SOAR appliance.
The resadmin sudo user password must be the same on both appliances.
If you are using custom certificates, the /crypt/certs/keystore file that contains the certificates used by the SOAR Web server is replicated to the SOAR appliance. It is recommended that clients such as browser, or integrations, address the SOAR Web server using a fully qualified domain name (FQDN) which allows the DNS record to be updated when you swap the active SOAR appliance to the second appliance. Alternatively, you can update the clients to point to the active SOAR appliance address. However, the certificates might need to use wildcards to be trusted on the newly active SOAR appliance.
You must have SSH keys configured for the user running the DR commands on the two appliances. From each appliance, as the resadmin user, make sure that it is possible to ssh to the local appliance and to the remote appliance.
Ensure that the SSH keys are set up correctly by opening an SSH session to each appliance and in doing so, do not specify a password.
```
ssh-keygen -t rsa -b 4096 -C "resadmin@machine_a"
ssh-copy-id -i /home/resadmin/.ssh/id_rsa.pub resadmin@machine_a
```
When prompted for a password, press Enter to leave it empty. It is a requirement to not specify a password. Then repeat for machine_b:
```
ssh-keygen -t rsa -b 4096 -C "resadmin@machine_b"
ssh-copy-id -i /home/resadmin/.ssh/id_rsa.pub resadmin@machine_b
```
Again, when prompted for a password, press enter to leave it empty. It is a requirement to not specify a password.
When you have completed this, it must be possible to run the following commands successfully from machine_a, which might be the primary appliance:
```
ssh resadmin@machine_a
ssh resadmin@machine_b
```
It must also be possible to run the same commands from machine_b, which might be the secondary appliance:
```
ssh resadmin@machine_a
ssh resadmin@machine_b
```
Ports 22 (ssh) and 5432 (postgres) must be open. Port 5432 only needs to be enabled on the primary appliance when DR is enabled. The ssh port 22 only needs to be enabled for the secondary appliance when DR is enabled, although it is likely that port 22 is open for both.