- 24 Jun 2022
- 2 Minutes to read
Decisions Disaster Recovery Architecture
- Updated on 24 Jun 2022
- 2 Minutes to read
A Disaster Recovery (DR) Server is typically a duplicate of the primary server in a different location. In the case of a "disaster" event on the Primary Server, the DR Architecture exists to ensure that the Decisions Server maintains uptime, and that the data is protected.
High Availability Servers are effective for Disaster Recovery in clustered environments by using a Load Balancer. In a clustered environment, the servers are typically located in the same data center; using a load balancer would make it so that if one node in the cluster fails, the traffic of that failing node is redirected to available nodes.
Primary vs. Disaster Recovery Database Connections
Primary Database Connection
The Primary Connection String from the installation will be the Database Connection that is used for the main server.
Disaster Recovery / Secondary Connection
The Secondary Connection String operates as a Failover Connection in the event that the Primary Connection String fails. For more information on how to configure this secondary connection string, please visit our
Configure Decisions as a Disaster Recovery server
In order to configure Decisions as a DR Server, at least two Decisions Installations will be needed. One of the installations is kept offline but references an MSSQL Database with Always-On Replication set for the Production Server. The Connection String applied to the Decisions Installer needs to reference the replicated database in the Disaster Recovery Server.
In addition, the Keys.dat and databaseid.txt file in the DR Server File System must be replaced with the same files from the Production Environment File System so that it can operate identically in a Disaster Event. While the DR server is not active, the settings.xml tag for this property should be set to <Offline>true</Offline>. Doing this prevents other users (with the exception of administrators) from logging into the server.
- Install Decisions to the Disaster Recovery Server on a new database; note that this database will need a name that differs from the database used for Always-On Replication.
- Stop the Decisions Server Service (or IIS App Pool).
- Run the DecisionsServerInstaller.exe on the Disaster Recovery Server again and select Edit Settings.
- Change the Initial Catalog field of the Database Connection String to match the name of the Always-On Replication Database.
- While modifying the Settings, make sure that Offline is set to true.
- Copy the Keys.dat and databaseid.txt files from the production server Decisions Services Manager directory and use them to replace the keys.dat and databaseid.txt files in the Disaster Recovery Server File System.
If the Decisions Server being backed up is a Multi-Tenant environment, navigate to the DR Server Settings.xml file, and set the <UseInstancePrototype> property to false.
The databaseid.txt file needs to be identical on the Production and Disaster Recovery Server as Scheduled Jobs operate differently if the file differs from the one present at the time of their creation, even if the database being used is identical.
Syncing Data To Disaster Recovery Server
For a full and comprehensive list of the recommended files to Backup from the Decisions environment, please visit our Decisions & File System Backup article.
The configurations in the Settings.xml file between the Primary Server and Disaster Recovery Server must match, with the exception of <Offline>true</Offline>.
The files in file storage are saved as regular files. This will require the IT team of the organization to determine the best method of file replication in the Disaster Recovery environment.
Keys.dat, Modules files, Databaseid.txt.