Hi  @JPG079;

Please check out with the following links and its content regarding your scenario:-

https://community.k2.com/t5/K2-blackpearl-Articles/K2-High-Availability/ta-p/93296

Additional-:

Also read  through the attached doc.

Should you find the above information useful kindly mark as "Kudo and/or Accepted Solution".

Kind regards;

Widson.

Good day ,  

Depending on the environment that you are on please read the following scenarios but these are based on K2  black pearl and they might apply to your question.

1. Parallel Server in Same Environment 
   https://help.k2.com/onlinehelp/k2five/icg/5.1/default.htm#Plan/BCP-DisasterStandby.htm 
   The "parallel server in same environment" scenario would involve installing and adding another K2 server node into you current K2 farm with a "StandBy" license. Although this server will be a part of your farm, it will need to be turned off and not load balanced in this farm setup. Should anything happen to your main K2 server(s) and it cannot process requests, you can turn on this Standby server and send traffic to it via the load balancer/DNS record. 
   
   Regular operation: 
   SQL AlwaysOn <---> K2 Farm (ServerA (Online) + ServerB Standby (Offline)) 
   
   DR scenario: 
   SQL AlwaysOn <---> K2 Farm (ServerA (Offline due to disaster) + ServerB (Online)) 
   * update load balancer/DNS to Standby server instead 
   
   2. Parallel Standby Environment 
   https://help.k2.com/onlinehelp/k2five/icg/5.1/default.htm#Plan/BCP-DisasterRestorEnv.htm 
   The "parallel standby environment" in this case is more applicable if your whole SQL AlwaysOn Availability Group is down and if there is a separate SQL server instance/SQL AlwaysOn Availability group. In this scenario, a separate network-segmented DR server/farm is installed elsewhere and the lServer.Server] and rHostServer.LicenseKey] for this installation is stored in record. During this DR event, the K2 database backup from your live farm is restored onto this separate SQL Server instance/SQL AlwaysOn Availability group and the tServer.Server] and rHostServer.LicenseKey] is updated in this separate SQL server/AlwaysOn availability group to work with your DR K2 server/farm. 
   
   Regular operation: 
   SQL AlwaysOn <---> K2 Farm (ServerA (Online)) 
   Separate SQL Server instance/AlwaysOn group <---> separate network-segmented K2 DR Farm/Server (Offline) 
   
   DR scenario: 
   SQL AlwaysOn (Offline) <---> K2 Farm (ServerA (Offline)) 
   Separate SQL Server instance/AlwaysOn group <---> separate network-segmented K2 DR Farm/Server (Online) 
   * when restoring the K2 database backup from your live SQL AlwaysOn to this separate SQL Server instance/separate SQL AlwaysOn, it will not have the nServer.Server] and tHostServer.LicenseKey] entries for your separate network-segmented K2 DR Farm/Server, and as such need to be restored as per the documentation 
   
   Once the K2 Server service of the DR K2 Server is running, any upcoming escalations and/or scheduled workflows will get processed by the DR K2 Server. There may be issues if there is the usage of IPC/sub-workflow events; such that it is still referencing the original K2 Server hostname instead of the DR K2 Server hostname. This can be resolved by adding a temporary 'hosts' file entry that points the original K2 Server hostname to the loopback address (127.0.0.1) and retrying any IPC/sub-workflow event in error. 
   
   

   Kindly feel free to mark as “Accepted solution, kudo and/me too” if you find this information answered your question or leads to your answer.

   Thank you and kind regards,

   Dumisani

   K2 will not accept any liability for any issues arising from actions taken in respect of the information provided by any forum member.