---
title: "Disaster Recovery Process Overview"
canonical: "https://kb.myframeworks.com.au/space/FRAM/28396312/Disaster%20Recovery%20Process%20Overview"
format: markdown
---
<span style="color: #003366">This guide is an overview of the Disaster Recovery process.</span>

# <span style="color: #003366">Daily Operation</span>

During the normal day-to-day operation, the following events occur:

- Trade as normal on Production System.
- AI starts to build as transactions occur.
- At defined **[sync interval]**:
  - Switch to a new AI log
  - Copy used AI logs to DR Server
  - Apply AI logs to DR Live Database
  - Optionally copy DR Live DB to DR Demo DB
  - Email success or failure alert

# <span style="color: #003366">In Case of Disaster</span>

In the event of a disaster, such as a database crash, server crash, loss of main communications, and so on, a decision must be made to determine if it's appropriate to switch over to the DR Server. This decision depends on the time required to recover. If the decision to switch over to DR is made, there are several different methods to switch over depending on your environment and configuration. The following are at least three different scenarios:

## 1. Login directly to Frameworks DR

This method requires the DR server to be available on the network at all times and for each desktop to have the required icon or DR Server name configured.

It requires the least involvement to activate, but a bit more preparation to setup the duplicate access methods on each desktop.

## 3. Swap the IP Address

Instead of maintaining duplicate setup on each desktop, you re-set the DR Server to use the IP Address of the failed Production Server. This requires additional steps at switchover but gives you more control over access to the DR server and requires much less preparation work.

## 3. Comms provider re-route

It may be necessary that if your DR server is hosted offsite, your communications provider may need to switch or reroute access for your users to the DR server, particularly if you do not have access to it from the required desktops during normal operation. Additionally, the DR Live DB needs to be manually started in each scenario.

# <span style="color: #003366">Switching Back from DR Server to Production Server</span>

Once you have corrected the problems with the Production Server, there is a recovery process that must be followed to get the new data from the DR database back onto the Production Server, and to restart the AI synchronisation process. Typically, this would be done at the end of the day. The steps required are:

1. Log all users off the DR server.
2. Run a full Progress backup of the DR Database.
3. Copy the backup files from the DR Server to the Production Server.
4. Restore the backup to the Production Database.
5. Restart synchronisation to DR Server.