Setting up DR (Disaster Recovery) Backups

Overview

Refer to the following sections in this article to learn about the different backup options when setting up a DR (Disaster Recovery) server:

• Setting up DR Servers
• Configuring DR Backups
  • Importing the Liquid Content Backup 
  • Requesting Infrastructure Team
  • Modifying DR Configuration to Synchronize Tenant ID
• Conclusion/Recommendation

Setting up DR Servers

When setting up a DR server, it is necessary to re-apply the license since it is limited to the previous server, and it will become invalid in the new DR server even if it is still listed in the database.

After setting up, no Content is missed in the pages since all data for the Microservices is cached locally in the new DR server. Nevertheless, the Content Library and Forms menus become empty since this server has a different Tenant ID.

Back to Top

Configuring DR Backups

Setting up a new DR server works as intended if the server is a temporary read-only server until the Production server is brought up. However, in the situation where the Production server will be replaced with the DR server, refer to the following approaches to ensure the availability of the Microservices on the DR instance:

Importing the Liquid Content Backup 

This option only works for copying the Liquid Content into the DR server. However, the Form Builder data is not copied with this option. Additionally, the automation of the Exports is not possible at the moment, and one would need to create the requests manually, or develop a module/script to call the endpoint with the required export arguments. 

For example, one can manually create thirty exports of the Content Library without the 'Run Now' option. These exports go to the queue and wait for the Export/Import task to execute, beginning with the oldest request.

Create a request for our infrastructure team to copy all the Microservices data from the old Tenant ID into the new one. This approach guarantees that all of the data is copied into the new instance, and all Content is available as soon as the team completes the task.

For this approach, please ensure to save the existing Tenant ID of your instance somewhere safe, as it will be necessary to send us both the Production Tenant (old) and the DR IDs.

Note: You can find the Tenant ID by going to Settings > Site Settings > Site Behavior > More in the DNN Persona Bar.

Requesting Infrastructure Team to Copy Tenant ID

Alternatively, place a request with our Support team, and we can reach out to the Infrastructure team to map your DR Tenant ID to the contents of the Production Tenant ID. This needs to be done before the DR server is used.

Nevertheless, please note that any changes made in the DR server will affect Production since both are connected to the same data. Furthermore, the data in the Tenant ID for the DR server changes will not be available in the future due to changes in the connection string.

Modifying DR Configuration to Synchronize Tenant ID

You may tweak the DR configuration to have the same Tenant ID as Production and ensure that the Content is available as soon as the application is started. To understand this approach, one needs to know how the Tenant ID is generated.

In this case, the Tenant ID is generated by using the HOST GUID and a hash of the connection string. The GUID is stored on the HostSettings table in the database and is the same for both Production and the DR server. Nevertheless, what makes the Tenant IDs different is the connection string in the web.config file since the database server or database name is usually different for each server. 

The idea with this approach is to have the same database details on the DR server connection string and make use of the local hosts file to point to the correct server.

For example, let us suppose that the Production points to the DBPROD server that has:

• The IP address 10.0.0.100; and
• The connection string connectionString="Data Source=DBPROD;....

While the DR points to the DBDR server that has:

• The IP address 10.0.0.200; and
• The connection string connectionString="Data Source=DBDR;....

Since both Tenant IDs are different, we can:

• Modify the DBDR connection string to match Production connectionString="Data Source=DBPROD;...; and then
• Inside the hosts files of the DBDR server, add an entry to point DBPROD to 10.0.0.200.

This way, the DR server becomes connected to the DBDR database while maintaining the same Tenant ID as the Production. 

Back to Top

Conclusion/Recommendation

The approach of modifying DR configuration to synchronize the Tenant ID is highly recommended as it adds more local control. However, if it is not possible to go with this approach, then request the infrastructure team to copy the Tenant ID once DR is deployed. Remember, the old Tenant ID is needed for this copy.

Back to Top